The Cybersecurity and Infrastructure Security Agency issued advisories on July 7, 2026, for two vulnerabilities affecting Digi International PortServer TS and Digi One SP IA devices used in critical sectors like manufacturing, communications, IT, and transportation. CVE-2026-12352 allows attackers to bypass authentication and access restricted resources (CVSS 5.9 Medium in v3.1, 8.2 High in v4.0). CVE-2026-12948 enables administrators to inject stored cross-site scripting into system configuration fields (CVSS 3.8 Low in v3.1, 4.8 Medium in v4.0). These vulnerabilities affect firmware versions below 2025.
The significance of these advisories lies not in the CVSS scores but in what they reveal about vulnerability management gaps in operational technology (OT) environments. In these settings, patching windows can extend from weeks to months, and a single authentication bypass can expose entire network segments.
Key Findings
Authentication bypass vulnerabilities in OT create cascade risks. CVE-2026-12352 doesn't require credentials. In environments where these devices manage serial-to-Ethernet connections for industrial equipment, an attacker who bypasses authentication gains a foothold into systems not designed with network segmentation in mind. Your firewall rules assume authenticated sessions, and your SIEM correlation rules look for failed login attempts. Neither catches an attacker who never authenticates.
Stored XSS in administrative interfaces weaponizes privileged users. CVE-2026-12948 requires administrative access to inject the malicious script, but that script executes in every subsequent administrator's browser session. In OT environments where a single administrative account often manages multiple devices, this creates a force multiplier. One compromised admin session can lead to credential harvesting across your entire device fleet. The CVSS score of 3.8 doesn't capture this operational reality.
CISA's defensive measures acknowledge patch management challenges. The advisory recommends minimizing network exposure and ensuring devices aren't internet-accessible. This isn't generic advice; it's recognition that firmware updates in OT environments require maintenance windows, operational testing, and change control processes that can take months. Your vulnerability management program needs a separate track for devices where patching isn't the primary control.
Firmware version threshold creates a binary decision point. You need to know not just that you have Digi PortServer devices, but which firmware version each one runs. If your configuration management database doesn't track firmware versions for OT devices, you're starting from an incomplete asset inventory. You can't scope your exposure without that baseline.
Defense-in-depth for OT means prioritizing network segmentation. CISA's recommendation to minimize network exposure reflects a fundamental principle: in environments where you can't patch quickly, reduce attack surface by controlling network paths. If your Digi devices sit on a flat network accessible from IT systems, you've already failed the first layer of defense-in-depth.
What This Means for Your Team
Your GRC program needs to answer three questions about these vulnerabilities, and the answers will expose gaps in how you've operationalized risk management for OT assets.
First: can you produce a complete inventory of affected devices within 24 hours? If you're relying on IT asset management tools that don't track OT serial-to-Ethernet converters, you can't. You need an OT-specific asset inventory that includes firmware versions, network locations, and criticality ratings tied to operational impact, not just data classification.
Second: do your compensating controls actually compensate? If you can't patch immediately, your risk acceptance documentation needs to specify what controls you've implemented instead. "Network segmentation" isn't specific enough. You need to document which VLANs these devices sit on, what firewall rules restrict access, whether you've implemented application-layer inspection, and how you're monitoring for exploitation attempts. Your auditors will ask for evidence that these controls reduce risk to an acceptable level.
Third: does your vulnerability management policy differentiate between IT and OT patching timelines? If your policy mandates patching critical vulnerabilities within 30 days regardless of asset type, you've created a compliance obligation you can't meet. You need separate SLAs for OT vulnerabilities that acknowledge longer testing cycles and maintenance windows, with compensating controls required during the extended remediation period.
Action Items by Priority
Immediate (within 48 hours): Inventory all Digi PortServer TS, Digi One SP, Digi One SP IA, and Digi One IA devices in your environment. Document firmware versions and network locations. If you don't have this data in your CMDB, you'll need to scan OT networks or pull it from device configurations manually. Create a tracking spreadsheet that includes device serial numbers, firmware versions, operational criticality, and network segment.
Within one week: Verify network segmentation for affected devices. Confirm they're not accessible from the internet. If they're on VLANs shared with IT systems, document the firewall rules that restrict access. If there are no firewall rules, implement them immediately. At minimum, restrict access to these devices to specific source IP addresses for administrative personnel who need to manage them.
Within two weeks: Assess your ability to upgrade to Firmware_2025 or later. Contact your operational teams to identify maintenance windows. Document dependencies: what processes or equipment will be affected during the firmware update? What testing is required before you can deploy to production? Build a phased rollout plan that starts with least-critical devices.
Within 30 days: Implement monitoring for exploitation attempts. Configure your SIEM to alert on unusual authentication patterns to these devices, even though CVE-2026-12352 bypasses authentication. Monitor for configuration changes that could indicate stored XSS injection. If you don't have visibility into these devices in your SIEM, that's a separate gap to address.
Ongoing: Update your vulnerability management procedures to include OT-specific patching workflows. Document the extended timelines, required testing, and compensating controls. Make sure your risk acceptance process includes signoff from operational stakeholders who understand the impact of taking devices offline for maintenance.
