ABB has disclosed that ABB Ability Zenon installations using IIoT Services with bundled MongoDB 4.2 need remediation now, but the company is not delivering a normal product patch. Administrators must either manually replace the database component with a supported MongoDB release or uninstall IIoT Services where they are unused. MongoDB 4.2 reached end of life on April 30, 2023, and one of the flaws present across the entire 4.2 branch, CVE-2025-14847, is already listed by CISA as actively exploited.
The advisory, first issued by ABB PSIRT on July 30 and republished by CISA on August 6, applies to every ABB Ability Zenon version only when IIoT Services with MongoDB 4.2 are installed. That qualification is the first thing Windows and OT administrators should verify. This is not a blanket finding against every Zenon engineering workstation, Runtime installation, or historian; it is a finding against a specific installed dependency and feature set.
The material operational problem is that ABB has acknowledged an obsolete server component in an industrial software deployment but has put the migration work on customers. Its published mitigation says administrators can manually configure Zenon IIoT Services to use a supported, patched MongoDB version, or remove IIoT Services using the Windows Control Panel uninstaller. ABB does not identify a replacement Zenon build, a supported MongoDB target version, a migration utility, a compatibility matrix, or a rollback procedure.
For environments where Zenon IIoT functions support production data collection or integrations, this is a change-management exercise, not a routine monthly patch.
The most urgent item in ABB’s advisory is CVE-2025-14847, widely known as MongoBleed. MongoDB’s own December 2025 security update says the flaw stems from mismatched length fields in Zlib-compressed protocol headers. An unauthenticated network client can cause MongoDB to return uninitialized heap memory, potentially disclosing data that happened to reside in process memory.
Every MongoDB Server 4.2 release is affected. There is no “latest secure” 4.2 build to install because the branch is no longer supported, and MongoDB’s published fixes begin with supported releases such as 4.4.30, 5.0.32, 6.0.27, 7.0.28, 8.0.17, and 8.2.3. The database vendor’s legacy-support policy records MongoDB 4.2’s end-of-life date as April 2023, more than three years before ABB issued this notice.
CISA added CVE-2025-14847 to its Known Exploited Vulnerabilities catalog on December 29, 2025. The National Vulnerability Database records CISA’s assessment as active exploitation that can be automated, while independent reporting from Akamai and Palo Alto Networks’ Unit 42 described the flaw as remotely reachable and unauthenticated. That does not establish that a Zenon deployment has been attacked, but it removes the usual comfort of treating an old library CVE as a merely theoretical exposure.
CISA’s August 6 industrial-control-system advisory says it has received no reports of public exploitation “specifically targeting” the ABB Ability Zenon vulnerabilities. Read narrowly, that refers to observed campaigns against Zenon installations. It should not be read as meaning the primary MongoDB weakness is unexploited: the underlying MongoDB CVE is in CISA’s exploited-vulnerability catalog.
The practical distinction is important. A Zenon IIoT Services machine that has no reachable MongoDB listener has a substantially smaller exposure than one reachable from a corporate network, vendor VPN, DMZ host, or improperly segmented engineering subnet. But segmentation does not cure the software defect, and unauthorized access through another internal system can still supply the network position MongoBleed requires.
Those entries reinforce ABB’s core conclusion: a bundled 4.2 deployment may carry years of unfixed defects. Yet a review of the individual CVE records shows that the vendor’s roll-up is not as clean as its 7.8 severity headline suggests.
CVE-2020-7929, for example, is listed by ABB as affecting the Zenon MongoDB 4.2 deployment. The National Vulnerability Database says the regular-expression denial-of-service flaw affects MongoDB Server 3.6 before 3.6.21 and 4.0 before 4.0.20. It does not list MongoDB 4.2 as affected.
Two other CVEs concern components other than MongoDB Server itself. CVE-2021-20328 is a hostname-validation issue in specific MongoDB Java drivers using client-side field-level encryption and a key-management service. ABB’s advisory does not document that Zenon IIoT Services ship one of those vulnerable Java drivers, nor does it establish that field-level encryption is enabled. CVE-2021-20334 is a local privilege-execution issue in MongoDB Compass on Windows, affecting Compass versions from 1.3.0 through before 1.25.0. ABB’s alert identifies bundled MongoDB 4.2, not MongoDB Compass.
That last mismatch has a direct consequence for severity triage. The 7.8 CVSS score shown on ABB’s advisory page aligns with CVE-2021-20334, the MongoDB Compass issue requiring local access on a Windows machine. The remotely reachable, unauthenticated MongoBleed flaw is scored 7.5 under CVSS 3.1, with high confidentiality impact but no integrity or availability impact. A 7.8 headline therefore overstates the score of the most operationally relevant server flaw while mixing it with a separate Windows client component that ABB has not shown is present.
This does not make the advisory harmless. CVE-2025-14847 alone is enough to justify immediate action. It does mean administrators should avoid treating all 13 entries as equally applicable when documenting risk, setting compensating controls, or making an emergency-change case. The defensible finding is narrower and more serious: Zenon IIoT Services can contain a dead MongoDB branch with an actively exploited, pre-authentication data-exposure vulnerability.
That phrasing is useful but incomplete. Removing a Windows feature is straightforward only after an operator confirms that no dashboards, data collectors, integrations, services, or cloud-connected workflows depend on it. Replacing a database beneath a distributed industrial-data service needs the same discipline as a production database migration: preserve configurations and data, test authentication and service recovery, validate application connectivity, and retain a rollback option.
ABB does not publish in the advisory a supported-target version, explicit migration sequence, supported Windows and Windows Server combinations, or an answer to whether the bundled service account, firewall rules, TLS configuration, database paths, retention behavior, and backup procedure remain compatible with a customer-supplied MongoDB release. It directs customers to Zenon’s online help and local ABB service organization for implementation support.
The missing support matrix is consequential. MongoDB upgrades across major releases can require staged version changes and feature-compatibility handling; administrators should not assume that installing a current MongoDB package on the same Windows host, redirecting a connection string, and restarting services is a validated Zenon procedure. In a regulated or high-availability OT environment, the correct path is a vendor-supported maintenance plan and a test on a representative nonproduction system.
Administrators should perform four checks before the next maintenance window:
ABB says it had not received information indicating exploitation of this product-specific issue when it published the advisory. But MongoDB 4.2’s final security posture is already fixed by its end-of-life status, and the most important defect in ABB’s list has moved from disclosure to active exploitation. Zenon operators with IIoT Services should treat the database replacement or removal as the remediation milestone—not as a future vendor patch that may arrive.
The material operational problem is that ABB has acknowledged an obsolete server component in an industrial software deployment but has put the migration work on customers. Its published mitigation says administrators can manually configure Zenon IIoT Services to use a supported, patched MongoDB version, or remove IIoT Services using the Windows Control Panel uninstaller. ABB does not identify a replacement Zenon build, a supported MongoDB target version, a migration utility, a compatibility matrix, or a rollback procedure.
For environments where Zenon IIoT functions support production data collection or integrations, this is a change-management exercise, not a routine monthly patch.
MongoDB 4.2 leaves Zenon exposed to an exploited memory-disclosure flaw
The most urgent item in ABB’s advisory is CVE-2025-14847, widely known as MongoBleed. MongoDB’s own December 2025 security update says the flaw stems from mismatched length fields in Zlib-compressed protocol headers. An unauthenticated network client can cause MongoDB to return uninitialized heap memory, potentially disclosing data that happened to reside in process memory.Every MongoDB Server 4.2 release is affected. There is no “latest secure” 4.2 build to install because the branch is no longer supported, and MongoDB’s published fixes begin with supported releases such as 4.4.30, 5.0.32, 6.0.27, 7.0.28, 8.0.17, and 8.2.3. The database vendor’s legacy-support policy records MongoDB 4.2’s end-of-life date as April 2023, more than three years before ABB issued this notice.
CISA added CVE-2025-14847 to its Known Exploited Vulnerabilities catalog on December 29, 2025. The National Vulnerability Database records CISA’s assessment as active exploitation that can be automated, while independent reporting from Akamai and Palo Alto Networks’ Unit 42 described the flaw as remotely reachable and unauthenticated. That does not establish that a Zenon deployment has been attacked, but it removes the usual comfort of treating an old library CVE as a merely theoretical exposure.
CISA’s August 6 industrial-control-system advisory says it has received no reports of public exploitation “specifically targeting” the ABB Ability Zenon vulnerabilities. Read narrowly, that refers to observed campaigns against Zenon installations. It should not be read as meaning the primary MongoDB weakness is unexploited: the underlying MongoDB CVE is in CISA’s exploited-vulnerability catalog.
The practical distinction is important. A Zenon IIoT Services machine that has no reachable MongoDB listener has a substantially smaller exposure than one reachable from a corporate network, vendor VPN, DMZ host, or improperly segmented engineering subnet. But segmentation does not cure the software defect, and unauthorized access through another internal system can still supply the network position MongoBleed requires.
ABB’s advisory is broader than its confirmed server exposure
ABB’s machine-readable advisory lists 13 CVEs and maps each one to Zenon installations with MongoDB 4.2. Several genuinely affect the MongoDB Server 4.2 line, including older flaws that can permit memory disclosure or denial of service. CVE-2020-7928 affects 4.2 releases before 4.2.9 and permits an authorized database user to read arbitrary process memory through crafted queries. CVE-2020-7925 affects versions before 4.2.9 and can crash the service through specially constructed requests. CVE-2021-32040 affects 4.2 releases before 4.2.16 and can be used to trigger a MongoDB crash with an excessively long aggregation pipeline.Those entries reinforce ABB’s core conclusion: a bundled 4.2 deployment may carry years of unfixed defects. Yet a review of the individual CVE records shows that the vendor’s roll-up is not as clean as its 7.8 severity headline suggests.
CVE-2020-7929, for example, is listed by ABB as affecting the Zenon MongoDB 4.2 deployment. The National Vulnerability Database says the regular-expression denial-of-service flaw affects MongoDB Server 3.6 before 3.6.21 and 4.0 before 4.0.20. It does not list MongoDB 4.2 as affected.
Two other CVEs concern components other than MongoDB Server itself. CVE-2021-20328 is a hostname-validation issue in specific MongoDB Java drivers using client-side field-level encryption and a key-management service. ABB’s advisory does not document that Zenon IIoT Services ship one of those vulnerable Java drivers, nor does it establish that field-level encryption is enabled. CVE-2021-20334 is a local privilege-execution issue in MongoDB Compass on Windows, affecting Compass versions from 1.3.0 through before 1.25.0. ABB’s alert identifies bundled MongoDB 4.2, not MongoDB Compass.
That last mismatch has a direct consequence for severity triage. The 7.8 CVSS score shown on ABB’s advisory page aligns with CVE-2021-20334, the MongoDB Compass issue requiring local access on a Windows machine. The remotely reachable, unauthenticated MongoBleed flaw is scored 7.5 under CVSS 3.1, with high confidentiality impact but no integrity or availability impact. A 7.8 headline therefore overstates the score of the most operationally relevant server flaw while mixing it with a separate Windows client component that ABB has not shown is present.
This does not make the advisory harmless. CVE-2025-14847 alone is enough to justify immediate action. It does mean administrators should avoid treating all 13 entries as equally applicable when documenting risk, setting compensating controls, or making an emergency-change case. The defensible finding is narrower and more serious: Zenon IIoT Services can contain a dead MongoDB branch with an actively exploited, pre-authentication data-exposure vulnerability.
The absence of an ABB patch changes the remediation plan
ABB calls this a “security risk due to end-of-life MongoDB component,” rather than announcing a Zenon hotfix. Its prescribed path is to replace the bundled database through manual configuration if IIoT Services are required, or uninstall IIoT Services if they are not. The company says removal eliminates the MongoDB dependency without affecting other Zenon components.That phrasing is useful but incomplete. Removing a Windows feature is straightforward only after an operator confirms that no dashboards, data collectors, integrations, services, or cloud-connected workflows depend on it. Replacing a database beneath a distributed industrial-data service needs the same discipline as a production database migration: preserve configurations and data, test authentication and service recovery, validate application connectivity, and retain a rollback option.
ABB does not publish in the advisory a supported-target version, explicit migration sequence, supported Windows and Windows Server combinations, or an answer to whether the bundled service account, firewall rules, TLS configuration, database paths, retention behavior, and backup procedure remain compatible with a customer-supplied MongoDB release. It directs customers to Zenon’s online help and local ABB service organization for implementation support.
The missing support matrix is consequential. MongoDB upgrades across major releases can require staged version changes and feature-compatibility handling; administrators should not assume that installing a current MongoDB package on the same Windows host, redirecting a connection string, and restarting services is a validated Zenon procedure. In a regulated or high-availability OT environment, the correct path is a vendor-supported maintenance plan and a test on a representative nonproduction system.
Inventory IIoT Services before treating every Zenon machine as affected
The immediate task is to separate Zenon estates that merely exist from systems that actually deploy the vulnerable database dependency. ABB’s product tree is explicit: the affected relationship is “IIoT services with MongoDB 4.2 installed on ABB Ability Zenon,” across Zenon versions.Administrators should perform four checks before the next maintenance window:
- Confirm whether IIoT Services are installed on each Zenon host, especially Windows servers handling collection, processing, integration, or web-facing IIoT functions.
- Identify whether a MongoDB 4.2 process is installed locally, what interface and port it listens on, and which network paths can reach it from engineering, business, remote-access, and DMZ segments.
- Establish whether any integration relies on IIoT Services before using the Windows uninstaller, and take tested application and database backups before changing the dependency.
- Engage ABB for the supported procedure to substitute a currently supported MongoDB version, including validation of Zenon functionality after the change.
ABB says it had not received information indicating exploitation of this product-specific issue when it published the advisory. But MongoDB 4.2’s final security posture is already fixed by its end-of-life status, and the most important defect in ABB’s list has moved from disclosure to active exploitation. Zenon operators with IIoT Services should treat the database replacement or removal as the remediation milestone—not as a future vendor patch that may arrive.
References
- Primary source: CISA
Published: 2026-08-06T12:00:00+00:00
ABB Ability Zenon | CISA
www.cisa.gov
- Related coverage: nvd.nist.gov
NVD - CVE-2023-3324
nvd.nist.gov
- Related coverage: nvd.nist.gov
NVD - CVE-2026-41717
nvd.nist.gov
- Related coverage: library.e.abb.com
- Related coverage: cisa.gov
- Related coverage: cyber.gc.ca
MongoDB security advisory (AV25-862) - Update 1 - Canadian Centre for Cyber Security
MongoDB security advisory (AV25-862) - Update 1www.cyber.gc.ca - Related coverage: advisories.ncsc.nl
