The short version
On August 6, 2026, CISA published ICSA-26-218-01 for ABB Ability Zenon, the SCADA, HMI, and IIoT platform used across energy, water, manufacturing, and food and beverage. The advisory lists 13 vulnerabilities, CVSS v3 up to 7.8, and describes the impact as bypassing security, crashing systems, executing unauthorized actions, or compromising data.
What stands out is where those flaws live. None of them are in Zenon's control logic. All 13 sit in a MongoDB 4.2 database that ABB's IIoT services bundle inside the platform. The newest one, CVE-2025-14847, lets an unauthenticated client read uninitialized memory through a malformed compressed header. The rest are MongoDB Server issues from 2020 and 2021, from authorization bypass to denial of service.
That distinction matters for how you respond. You do not get to upgrade a database ABB ships inside its product. It moves on ABB's release cycle, which on a validated, uptime-critical system can be slow. So the useful response is not to wait, it is to change what can reach the thing.
What the advisory says
Straight from the advisory and the CVE records:
- Product: ABB Ability Zenon. The affected component is ABB IIoT services with MongoDB 4.2, listed across all versions of that setup.
- The flaws: 13 CVEs. One is new, CVE-2025-14847, an unauthenticated heap read. The rest are MongoDB Server CVEs from 2020 and 2021, including CVE-2020-7921 (an authorization-subsystem flaw that allows an IP-allowlist bypass), CVE-2020-7925 (a parser flaw an unauthenticated attacker can hit), and a run of denial-of-service and memory-access bugs (CVE-2020-7928, 7929, 7923, 7924 and CVE-2021-20330, 32036, 32040, 20333, 20328, 20334).
- Severity: CVSS v3 up to 7.8.
- What it enables, per CISA: bypass security, crash systems, execute unauthorized actions, or compromise data.
- How it is reached: the network-facing bugs need an attacker who can open a connection to the database. Some need no account at all.
- Remediation: ABB has guidance in the advisory. CISA adds its usual line for ICS: keep the system off the public internet, isolate it from the business network, and route remote access through a controlled path.
CISA did not report anyone exploiting this in the wild. Read it as exposure to close, not a fire to put out.
Why this keeps happening
Read past the ABB name and this is a story about what every OT platform is built from. None of these products are one binary. Vendors bundle databases, historians, web servers, message brokers, and language runtimes to ship features faster, and every one of those carries its own vulnerabilities into your plant.
The trouble is the timeline. You cannot swap out the bundled MongoDB without risking support and re-validation on the platform that depends on it. The real fix arrives when ABB rebuilds and reships, and in OT that can take a while against a certified system nobody wants to reboot. In the meantime the component keeps doing its job, answering on a port, on a network, exactly as designed.
A 4.2-era database carrying five-year-old CVEs inside a 2026 platform is not sloppiness. It is the normal gap between when a dependency ships a fix and when a vendor can safely fold it into an industrial product. The exposure is baked into how OT software is assembled, so patching alone will always be a step behind it.
What actually gets exploited
Underneath the CVE list the risk is plain. An attacker reaches a database that should never have been reachable, and talks to it. For the unauthenticated flaws that is the entire attack. No malware, no zero-day chain, no stolen account. Network reach and a crafted request.
Which is why CISA's advice on this advisory is the same advice it prints on almost every one: do not expose the system, isolate it, and put remote access behind a controlled path. The bugs are ABB's to fix. Reachability is yours.
The question worth asking on your own network is not whether MongoDB is patched. It is what can currently open a connection to the IIoT services, and whether you would see it if something did. On a flat plant network the answer is usually everything on the subnet, and no.
The control that actually bounds it
You close this without the patch by making the component reachable only through an enforcement point.
An industrial proxy sits in the access path to the ABB Ability Zenon IIoT services and brokers every session that reaches them. In practice:
- The database stops answering arbitrary clients on the subnet. The only way to it is a session the proxy has already authenticated, which means the unauthenticated flaws lose the thing they need most, an unauthenticated caller.
- Every session is tied to a named person or service, scoped to what the work requires, with MFA handled at the proxy. Nothing on the ABB stack is modified, so nothing has to be patched, re-validated, or rebooted for this to hold.
- Every session that touches the IIoT services is logged, so "would we notice" finally has an answer.
- It installs nothing on the platform. It is an IEC 62443 conduit between the control zone and everything above it, which is the industrial DMZ idea scoped down to a single bundled component.
This does not replace patching. Apply ABB's remediation when your change process allows. What it buys you is time that patching cannot: the exposure is closed now, it stays closed through the next embedded-component CVE you have not read about yet, and none of it touches a certified system you cannot afford to disturb. The mechanics are in what an industrial proxy is, and the audit side is in OT microsegmentation with SIEM integration.
The Johnson Controls advisory, briefly
CISA shipped a second advisory the same day, ICSA-26-218-02, for the Johnson Controls TL280 network alarm communicator in critical manufacturing. The flaw is hardcoded credentials in the firmware (CVE-2026-27871, CVSS v3 4.1), and Johnson Controls fixes it with a firmware update.
Lower stakes, different box, familiar shape. You cannot un-hardcode a credential in someone else's firmware. What you can do is make sure the device only answers on a path that authenticates and logs whoever connects, so a leaked static credential is not the same as an open door. Two advisories, one day, same underlying move.
Where to start this week
- Locate ABB Ability Zenon and its IIoT services in your environment, and note which segments can currently open a connection to them.
- Confirm the database is not reachable from the business network or the internet. If it is, close that first.
- Apply ABB's remediation on your normal change process and track it, but do not let the patch date be the only thing between an unauthenticated client and the component.
- Move the IIoT services behind an enforcement point so access is identity-bound, least-privilege, and recorded.
- Run the same check on the other bundled pieces of your SCADA and HMI stack. The next advisory will name a different database or runtime, and the response will not change.
ICSA-26-218-01 is a good prompt to fix something broader than one component. In OT you rarely get to patch the flaw on your timeline, so you set the terms on what can reach it instead.