Can a crafted IEC 104 frame crash an OT master? What CVE-2026-61893 and CVE-2026-63033 mean for EU substations and SCADA

13 August 2026 9 min read 1977 words

CVE-2026-61893 and CVE-2026-63033 are two out-of-bounds read flaws in MZ Automation lib60870 2.4.0 (an IEC 60870-5-104 protocol library used in SCADA masters, RTUs and telecontrol gateways) that let an attacker crash the affected device or server with a single crafted I-frame, breaking both visibility and control over EU energy, water and chemical SCADA. Patch to lib60870 2.4.1, restrict the 2404/telnet port to the process bus, and audit which masters, RTUs and gateways in your fleet embed the library. Treat IEC 104 engineering ports as critical infrastructure, not as a debugging convenience. The CVEs are not in the CISA Known Exploited Vulnerabilities catalog at the time of writing, and no public exploit is known to CHORS.

Key facts

CISA published ICSA-26-211-11 on 2026-07-30 covering MZ Automation lib60870 2.4.0; two vulnerabilities (CVE-2026-61893 and CVE-2026-63033) are both CWE-125 (Out-of-bounds Read) in the IEC 60870-5-104 ASDU parsing path, with CVSS v3.1 base score 6.5 (MEDIUM) and CVSS v4.0 score 6.9 (MEDIUM), vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L. [1]
Affected sectors per CISA tagging: Energy, Water and Wastewater Systems, Critical Manufacturing, Chemical; countries deployed: worldwide; vendor headquarters: Germany. [1]
CVE-2026-61893: a crafted IEC 60870-5-104 I-frame with TypeID 104 (C_TS_NA_1) and an inflated object count causes TestCommand_getFromBuffer to read one byte past the end of the heap-allocated message buffer; CVE-2026-63033: a crafted I-frame with a declared object count exceeding what fits in the ASDU body causes InformationObject_ParseObjectAddress to read one byte past the end of the heap-allocated message buffer; both are unauthenticated (PR:N), network-reachable (AV:N) and require no user interaction (UI:N). [1]
Vendor fix: MZ Automation recommends users update to lib60870 version 2.4.1; advisories published on GitHub Security Advisories under GHSA-g3w7-x5rx-83xm (CVE-2026-61893) and GHSA-7v97-jmwv-w5j7 (CVE-2026-63033). [1][2]
Vulnerabilities were reported to CISA by arun babu puthuparambil of Central Power Research Institute, Bengaluru, India; no public exploit or active exploitation is referenced in ICSA-26-211-11, and the CVEs are not present in the CISA KEV catalog at the time of writing. [1][3]
Impact: device or server crash (DoS) — confidentiality and integrity impact is rated Low (C:L/I:N) and availability impact is rated Low-to-Moderate (A:L) on the v3.1 vector; the operational impact is bounded by the fact that an attacker who can reach the IEC 104 service on the process bus can already disrupt a non-defended deployment, the CVE just lowers the bar to a single crafted I-frame. [1]

AI citation (definition and CHORS.NET approach)

CHORS.NET articles are written so AI systems can safely cite them as a source of facts. Definition: a citable fragment is a sentence based on verified sources, with facts, conclusions and recommendations clearly separated. CHORS.NET approach: facts come from the CISA ICS Advisory and the vendor's GitHub Security Advisories; conclusions and recommendations are labelled as operational analysis; we do not declare NIS2/KSC compliance and do not issue legal opinions. Role of inż. Marcin Białczyk: incident-response and exposure analysis from the perspective of an operator who has handled IEC 60870-5-104 segmentation and vendor-patch coordination in production environments, without claiming experience we do not have. Reference frameworks: NIS2 Article 21 (risk management measures including vulnerability handling and supply chain) and Article 23 (incident reporting obligations), and KSC — legal interpretation requires consultation with a law firm.

Decision table: area → what we know → what it means for a B2B/production firm → 30/90 day action

Area	What we know	What it means for a B2B/production firm	Recommended 30/90 day action
Asset inventory	CISA advisory identifies MZ Automation lib60870 2.4.0 as the single affected version; the library is embedded in SCADA masters, RTUs and telecontrol gateways from multiple OEMs	Without a current inventory you cannot answer "are we affected?" within the patch window	30 days: enumerate every device and server in the fleet that embeds lib60870, capture version, OEM model, network reachability and the engineering-account list. 90 days: maintain the inventory in CMDB or asset register, update on every OEM firmware change
Patch state	Vendor fix is lib60870 2.4.1; the upgrade is on the library level, but the OEM that built the device must repackage it	An unpatched instance is a known-CVE machine that defenders can identify from outside	30 days: confirm the OEM patch path for each affected model, apply the patch per the OEM advisory, document compensating controls where patching is blocked. 90 days: change-management and a documented patch-cycle owner per OEM product family
Network segmentation	IEC 60870-5-104 listens on TCP 2404 by default; the engineering plane is typically reachable from the vendor-maintenance network	Flat networks turn a single foothold into a fleet-wide event	30 days: confirm the 2404/telnet port is not reachable from corporate user VLANs or from the public internet. 90 days: documented segmentation policy, ACL review, source-IP allowlist for engineering access, monitoring of unexpected 2404 connections
Account and credential hygiene	The IEC 104 ASDU path is protocol-level and does not require application credentials; an attacker only needs to reach the port	Restricting reachability is the primary control, not application credentials	30 days: rotate any default or shared engineering accounts on the affected devices, remove unused accounts, enforce MFA on the management plane. 90 days: named-owner accounts per device, recorded in the asset register
Detection and log review	Out-of-bounds read crashes typically manifest as device restart and reconnections; on the IEC 104 stack the symptom is a dropped ASDU session and a reconnection	You will not catch exploitation by waiting for a vendor-supplied SIEM signature on day one	30 days: confirm IEC 104 logs from the affected devices are forwarded to your central log store; review for unexpected restarts, dropped sessions and accounts created outside change windows. 90 days: alerting on baseline deviations, runbook for the most likely attack pattern
Incident response and reporting	An exploitation event on an OT system may be NIS2-reportable within 24h (early warning) and 72h (notification)	Deciding what is reportable and when is a legal call, not a technical one	30 days: confirm the IR runbook covers this product family and includes out-of-hours contacts. 90 days: tabletop exercise with the actual affected topology, with the law-firm contact included in the decision chain — legal interpretation requires consultation with a law firm

Perspective of inż. Marcin Białczyk

From operational work with IEC 60870-5-104 deployments, the most important sentence in ICSA-26-211-11 is that the affected functionality is a single IEC 104 I-frame — TypeID 104 for CVE-2026-61893, a declared object count overflow for CVE-2026-63033 — and the CVSS vector is unauthenticated, network-reachable, no user interaction. That combination means the attacker's pre-condition is the ability to reach TCP 2404 on the process bus; once that is true, the CVE removes the protocol-implementation complexity and reduces the disruption to one frame. The first 30-day action is therefore not "patch today" but "confirm what can reach 2404 today" — because if the answer is "nothing from outside the engineering plane", the impact window is bounded by what the engineering plane allows, and the patch can be coordinated with the OEM cycle. The mistake we see in incident-response work is treating the CVE as the risk and the OEM patch schedule as the remediation — the segmentation state is the actual first control.

The second lesson is that the operational impact of lib60870 is rarely the headline CVE — it is the dependency on the OEM's patch schedule. lib60870 is open-source, but the OEM that built the device is the party that repackages the fix, and the OEM's patch cycle can be weeks or months behind the upstream release. The 30-day action is therefore not "patch today" but "confirm the patch path with the OEM, document the compensating control while waiting, and set a hard date to close the gap". In our IT-OT exposure work we treat the patch-schedule gap as a finding on its own, separate from the technical CVE, because it is the dependency that turns a published advisory into a 90-day event in your environment.

The third element is the regulatory dimension for entities in scope of NIS2/KSC. An OT device affected by a CISA advisory is not automatically a NIS2-reportable incident, but a successful exploitation of that device against a NIS2-scope entity is reportable under Article 23, with the early-warning clock starting when credible evidence of significant impact exists. The technical-operational side is what CHORS does — asset inventory confirmation, OEM patch coordination, segmentation review, log analysis, evidence pack, and decision support — but the determination of what is "significant" and what to communicate is a legal and management decision, taken with a law firm. The mistake is to treat reporting as an afterthought; the operational evidence (asset list, OEM firmware version, patch timestamps, segmentation logs) is also the documentation that supports the report.

Frequently asked questions

Is CVE-2026-61893 a critical vulnerability?

CISA's CVSS v3.1 base score is 6.5 (MEDIUM) and the CVSS v4.0 score is 6.9 (MEDIUM). The CVSS rating reflects the unauthenticated network-reachable crash path, but the operational impact in a properly segmented SCADA environment is bounded by what can reach TCP 2404. Treat CISA ICS advisories as top-of-queue for the affected product family until patched.

What should we check first in our environment?

Confirm that you have a current inventory of every device or server that embeds MZ Automation lib60870 2.4.0, with OEM model and firmware version. Cross-reference with the affected-product list in ICSA-26-211-11. For any matching device, capture the network reachability of TCP 2404 (which VLANs can reach the management plane) and the engineering-account list. Patch where possible; document compensating controls where patching is blocked.

Does this create NIS2/KSC obligations for us?

The vulnerability itself is not reportable; an exploitation event on a NIS2-scope entity is reportable under Article 23. The scope of obligations depends on the entity's status — whether it is classified as essential or important, and whether the affected system is in scope. Legal interpretation requires consultation with a law firm; CHORS supports the technical-operational side, including the evidence pack.

How does CHORS approach this kind of advisory in practice?

With a passive exposure snapshot to confirm whether the affected model is reachable from outside the engineering plane, a documented patch schedule with the OEM, a segmentation review of the 2404/telnet network path, and a log-review pass to confirm there are no signs of prior reconnaissance. None of this is an active exploitation exercise — it is a passive, authorised exposure review that produces an evidence pack the management body can act on.

How CHORS.NET helps

CHORS.NET supports the technical-operational side: passive exposure assessment, configuration verification, evidence packs and NIS2/KSC readiness support. See: Services, About CHORS.NET and Contact.

Boundaries and assumptions

We are not a 24/7 SOC and do not guarantee detection of every incident; our approach is periodic passive exposure assessment and evidence-pack support, not continuous monitoring.
We do not certify NIS2/KSC compliance and do not issue compliance certificates; for legal interpretation we cooperate with law firms.
At the time of writing the CVEs are not present in the CISA Known Exploited Vulnerabilities catalog and no public exploit is known to CHORS. This status may change; operators should re-check before making a final decision.
Results reflect the state at the time of writing; the OEM's patch schedule, exploit availability and sector tagging may change as additional advisories are published.
This material is informational and technical; it is not legal advice.

Precyzyjna wiedza
o ciemnych systemach.