Five ICS advisories from CISA on 19 May. Most of them you can manage through your normal patch cycle. Two of them you can’t, because there are no patches to apply.
Siemens RUGGEDCOM APE1808 has an unauthenticated root RCE. ScadaBR has four critical vulnerabilities including unauthenticated sensor data injection. Neither has a fix available. The ScadaBR vendor hasn’t responded to CISA at all.
RUGGEDCOM APE1808: an unpatched RCE at the IT/OT boundary
CVE-2026-0300 is a buffer overflow in the User-ID Authentication Portal service of PAN-OS, the operating system embedded in RUGGEDCOM APE1808 appliances. For context on where these devices live: substations, rail control networks, utility SCADA perimeters, manufacturing sites. The hardware is purpose-built for harsh industrial environments, and it sits precisely at the boundary between enterprise IT and operational technology networks.
The flaw requires no authentication. An attacker sends crafted packets, achieves code execution with root privileges. Every firmware version currently available for the APE1808 contains the vulnerable PAN-OS build. There is no patch.
Siemens and Palo Alto have published a workaround: disable the User-ID Authentication Portal and Response Pages on interfaces exposed to untrusted zones. For operators who depend on those features for network access control, that creates an operational problem. But the alternative is an unauthenticated root RCE on a device bridging IT and OT, which isn’t a trade-off worth making.
If RUGGEDCOM APE1808 devices are in your environment, this doesn’t wait for the next scheduled maintenance window. Disable the exposed features and watch for a patch.
ScadaBR: a complete attack chain, no vendor in sight
The ScadaBR advisory is worse. Four critical vulnerabilities in version 1.2.0, forming a chain that requires essentially no sophistication to weaponise. The vendor hasn’t responded to CISA’s coordination requests. No patch timeline exists.
The vulnerabilities, in the order an attacker would use them:
Hard-coded administrator credentials. Any attacker who has read the ScadaBR documentation can log in as admin. No exploitation required; just knowledge of the defaults.
OS command injection. An authenticated attacker can execute arbitrary commands as root on the underlying system. Combine this with the hard-coded credentials and you have unauthenticated root access in two trivial steps.
Unauthenticated sensor data injection. An unauthenticated attacker can send HTTP requests that overwrite live sensor readings with arbitrary values. This is where the risk moves beyond the conventional confidentiality/integrity framing into safety. Environments where operators make decisions based on sensor inputs (temperature, pressure, flow rate, electrical load) can be driven toward incorrect interventions. Injecting false normal readings masks real anomalies. Safety responses that should activate won’t.
Cross-site request forgery. Extends the attack surface to social engineering vectors by allowing authenticated actions via a victim’s active session.
ScadaBR is open-source SCADA software with a real deployment base, particularly in smaller industrial facilities that can’t afford proprietary platforms. These aren’t hypothetical targets; they’re organisations with limited IT security resources, legacy infrastructure, and now four publicly documented critical vulnerabilities and no vendor response.
What to do now
RUGGEDCOM APE1808:
- Disable the User-ID Authentication Portal and Response Pages on untrusted and internet-facing interfaces immediately
- Confirm these devices aren’t directly internet-accessible; if they are, that’s the first problem to fix
- Watch Siemens and Palo Alto security channels; apply any patch as soon as it’s available
ScadaBR:
- Change default credentials now, on every deployment
- Put network controls in place to prevent direct access from untrusted networks or the internet; ScadaBR should not be reachable from anywhere it doesn’t need to be
- Treat sensor data from affected systems as potentially manipulated until mitigations are in place
- Given the vendor’s non-responsiveness to CISA, start evaluating migration to a supported SCADA platform. This isn’t a comfortable thing to plan, but an unresponsive vendor with four unpatched critical CVEs is not a long-term foundation
Full advisories: ICSA-26-139-02 (RUGGEDCOM) and ICSA-26-139-03 (ScadaBR).