Unpatchable ICS Vulnerabilities: Mitsubishi, Schneider, Delta Among Vendors in CISA's Nine-Alert Batch

Nine industrial control system advisories released by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) on August 28, 2025, expose critical weaknesses in products from Mitsubishi Electric, Schneider Electric, Delta Electronics, GE Vernova, and Hitachi Energy. The batch reveals a stark reality: several Mitsubishi MELSEC iQ-F Series CPU modules will never receive a vendor fix, forcing plant operators to lean on network segmentation and compensating controls indefinitely. The coordinated disclosure covers a wide swath of operational technology—from PLCs and remote terminal units to Windows-based engineering suites and protection relays—and assigns CVSS scores as high as 8.8.

The August Advisory Package at a Glance

CISA published nine distinct advisories, each detailing affected versions, assigned CVEs, and vendor guidance. The following table summarizes the vulnerabilities.

Vendor-by-Vendor Breakdown

Mitsubishi Electric MELSEC iQ-F Series CPU Modules

Two advisories target the MELSEC iQ-F family, affecting a long list of FX5U, FX5UC, FX5UJ, and FX5S CPU models. The first (ICSA-25-240-01) highlights a missing authentication flaw on the MODBUS/TCP interface (CVE-2025-7405). An attacker who can reach the device over the network can read or write process values, stop program execution, or tamper with information—all without any credentials. The second (ICSA-25-240-02) is even more dangerous: SLMP messages are transmitted in cleartext (CVE-2025-7731), allowing an eavesdropper to capture credentials simply by sniffing network traffic. While CVE-2025-7405 carries a CVSS v4 score of 6.9, the credential-disclosure vector in CVE-2025-7731 jumps to 8.7.

Critically, Mitsubishi has stated that it does not plan to release firmware updates for many affected SKUs. The vendor’s mitigation guidance relies solely on firewalls, VPNs to encrypt SLMP traffic, IP filtering, and physical access restrictions. For thousands of deployed devices, this means the vulnerability will persist for their entire remaining lifecycle. Operators must assume that anyone with network access to these PLCs can compromise them, making rigorous network isolation the only practical defense.

Schneider Electric Saitel DR and DP Remote Terminal Units

Schneider’s advisory (ICSA-25-240-03) details an improper privilege management issue (CVE-2025-8453) in Saitel DR RTU versions through 11.06.29 and Saitel DP RTU versions through 11.06.34. An authenticated user with console access can exploit a root-level daemon to execute arbitrary code when configuration files are modified. With a CVSS v3 score of 6.7, the risk is moderate, but real: any technician with legitimate access could escalate to full control. Schneider has issued a firmware update (HUe 11.06.30) for the DR line, while a remediation plan for the DP line is still being established. In the interim, Schneider recommends restricting console and physical access, enforcing strict file permissions, and implementing strong password policies.

Delta Electronics CNCSoft-G2 and COMMGR

Delta’s Windows-based engineering tools receive two advisories. CNCSoft-G2 (ICSA-25-240-04) suffers from an out-of-bounds write (CVE-2025-47728) when parsing DPAX project files. An attacker who tricks a user into opening a malicious file can achieve remote code execution. With a CVSS v4 score of 8.5, the flaw demands urgent attention on any engineer’s workstation. Delta has released version 2.1.0.27 or later to address it.

COMMGR (ICSA-25-240-05), used for device management, is plagued by a stack-based buffer overflow (CVE-2025-53418) and a code injection vulnerability (CVE-2025-53419), both exploitable via crafted .isp files. Scores reach 8.8. Updating to COMMGR v2.10.0 or later closes these holes. Because file‑parsing RCEs require user interaction, security teams should pair patching with strict policies against opening untrusted project files and enforce application whitelisting on engineering hosts.

GE Vernova CIMPLICITY

CIMPLICITY, a widely used SCADA/HMI platform, contains an uncontrolled search path element (CVE-2025-7719) in versions 2024, 2023, 2022, and 11.0. A local low‑privileged user could elevate privileges by placing a malicious DLL in the application’s search path. CVSS v4 assigns a 7.0 score. GE Vernova recommends installing CIMPLICITY 2024 SIM 4 and adhering to its Secure Deployment Guide. Administrators should also audit ACLs on HMI servers and limit interactive logins to essential personnel.

Mitsubishi/ICONICS HMI and SCADA Suites

Advisory ICSA-25-140-04 (Update B) covers a privilege execution flaw (CVE-2025-0921) in GENESIS64 (all versions), GENESIS 11.00, and MC Works64 (all versions). A local attacker can manipulate symbolic links to write arbitrary files, leading to information tampering or denial of service on the Windows PC hosting the SCADA system. Although the CVSS v4 score is a moderate 6.8, the widespread deployment of these HMI suites makes the vulnerability significant. Users should upgrade to GENESIS 11.01 or apply vendor‑provided mitigations, and IT/OT teams must harden HMI machines by removing unnecessary administrator privileges and disabling unused services.

A separate advisory (ICSA-24-135-04, Update D) rolls up several older, lower‑severity CVEs—CVE‑2023‑51776, CVE‑2023‑51777, CVE‑2023‑51778—affecting a broad spectrum of Mitsubishi FA engineering tools, including GX Works2/3, GT Designer, and RT ToolBox3. While scores are low (CVSS v4 around 4.1–4.4), these tools are often installed on the very workstations that bridge IT and OT networks, making them attractive for lateral movement. Operators should consult Mitsubishi’s version‑update matrix and apply the latest builds.

Hitachi Energy Relion Protection Relays

The updated advisory (ICSA-25-184-01) describes an improper disk‑check condition (CVE-2025-1718) in Relion 670/650 and SAM600‑IO series devices. An authenticated FTP user with file‑access rights can cause the relay to reboot, disrupting protection functions with a CVSS v4 score of 7.1. Hitachi has enumerated specific fixed versions (e.g., 2.2.6.4, 2.2.5.8, or upgrading to 2.2.7). Because protection relays are critical to grid stability, upgrades must be validated on a test bench before field rollout to avoid unintended tripping.

Cross‑Cutting Observations

Remote vs. Local Exploitability Defines Priority

The batch illustrates a familiar OT risk spectrum. Remotely exploitable flaws, particularly the unauthenticated MODBUS access and cleartext credential leaks on Mitsubishi PLCs, present the largest blast radius. Conversely, local‑only issues (CIMPLICITY, GENESIS64) require an attacker to already have a foothold on the engineering host, which still warrants immediate remediation but can be triaged after the most urgent remote holes are closed.

Network Controls Remain the Primary Compensating Defense

When vendors decline to issue patches—as Mitsubishi has for many MELSEC iQ‑F SKUs—CISA and the vendors universally fall back on network‑layer controls. VPNs, industrial firewalls, IP filtering, and strict network segmentation are not optional add‑ons; they become the only defense layers between the vulnerability and an attacker. This reality forces a re‑evaluation of perimeter design and reinforces the Purdue model’s relevance.

Vendor Patch Disparity Reflects Lifecycle Realities

The advisory set exposes a sharp divide. Delta Electronics, Hitachi Energy, and Schneider (for the DR RTU) delivered clear, testable fixes. In contrast, Mitsubishi’s decision not to fix numerous CPU variants underscores a painful truth: legacy OT hardware often outlives its vendor support. Organizations must accelerate migration plans for unsupported devices and embed secure‑by‑design requirements into procurement.

Engineering Tools: The Perpetual IT‑OT Bridge

Multiple advisories target Windows‑based engineering or HMI applications—CNCSoft‑G2, COMMGR, CIMPLICITY, GENESIS64, and the broader Mitsubishi FA software suite. These tools are the classic pivot point where an IT compromise turns into an OT takeover. Hardening engineering workstations, maintaining rigorous patch cadences, and enforcing least privilege on these machines is as important as securing the PLCs themselves.

CVSS v4 Adoption Brings Nuance Without Changing Urgency

CISA continues to provide both CVSS v3.1 and v4.0 scores where available. While v4 sometimes produces a slightly higher or lower number, the takeaway for operators remains unchanged: any vulnerability scoring above 7.0 in either version demands swift, prioritized action.

Remediation Playbook for OT Teams

Operators facing this advisory package should follow a structured, asset‑centric approach.

1. Inventory and Prioritize: Identify every device matching the affected product lists. Tag each with its exposure level—internet‑facing, on the plant network, or air‑gapped—and classify by exploitability: remote, local, or user‑interaction required.
2. Apply Vendor Fixes in Staged Windows: For products with available patches (Delta COMMGR/CNCSoft‑G2, Schneider Saitel DR, Hitachi Relion, GE CIMPLICITY SIM 4), schedule maintenance windows. Validate every update on a test bench that mirrors the production environment, verifying that control logic, communication paths, and safety interlocks remain intact.
3. Implement Compensating Network Controls: Where patches are absent or pending, immediately enforce IP filtering, deploy VPNs for all SLMP traffic (Mitsubishi), and isolate vulnerable segments with industrial firewalls. Harden Windows engineering hosts with host‑based firewalls and application allow‑listing.
4. Restrict Access and Privileges: Limit console and RDP access to essential personnel only. Enforce least‑privilege accounts on HMI and engineering workstations. For Schneider Saitel DP RTUs, apply strict file ownership and permissions until patches arrive.
5. Increase Monitoring and Detection: Tune network IDS/IPS signatures for Modbus, SLMP, and FTP anomalies. Monitor for unexpected credential use and abnormal file transfers. Correlate logs from engineering workstations with OT network events.
6. Update Incident Response Plans: Ensure runbooks include scenarios for each high‑severity CVE, especially the credential‑stealing SLMP flaw. Define fallback operations—such as reverting to manual control—for devices that must be taken offline.
7. Engage Vendors and Plan Migration: Request formal roadmaps for products listed as “no fix planned.” Budget for lifecycle replacement of unsupported PLCs and RTUs, and make patch‑commitment SLAs a requirement in future RFPs.

The Bigger Picture: Lifecycle Gaps and Legacy Debt

This advisory batch is not a one‑off anomaly. It reflects a systemic tension in industrial environments: hardware is expected to run for decades, yet security researchers continue to find flaws faster than vendors can—or will—patch them. The Mitsubishi MELSEC iQ‑F situation is a case in point. Models that are otherwise fully functional will carry known, exploitable vulnerabilities for their entire remaining service life. For cash‑strapped utilities and manufacturers, replacing thousands of devices overnight is unrealistic, so they must double down on compensating controls.

Regulators and insurance providers are taking note. In many jurisdictions, failing to apply available patches or to implement recognized compensating measures can be interpreted as negligence, raising the stakes for compliance and liability. The CISA advisories themselves provide a defensible baseline: if an operator follows the explicit mitigations—even when a patch is absent—they can demonstrate due diligence.

Conclusion

The August 28 advisory package serves as a potent reminder that OT environments remain squarely in the crosshairs, and that vulnerabilities span the entire stack—from embedded firmware to Windows‑based HMIs. While Delta, Hitachi, and Schneider pushed out fixes rapidly, Mitsubishi’s refusal to patch numerous devices forces a permanent reliance on network‑level defenses. For plant managers and CISOs, the immediate priorities are clear: inventory assets, patch where possible, segment mercilessly, harden engineering hosts, and treat unsupported hardware as inherently hostile. By combining disciplined OT network hygiene with a realistic migration strategy, organizations can contain the risk and keep critical processes running safely.