Mitsubishi Electric has notified customers that it will not release firmware updates to address a critical authentication bypass vulnerability in its MELSEC iQ-F series programmable logic controllers (PLCs), leaving tens of thousands of industrial automation systems dependent on network isolation and access controls for protection. The vulnerability, tracked as CVE-2025-7405 and detailed in a CISA advisory published August 28, 2025, allows unauthenticated remote attackers to read and write device registers and halt program execution via the PLC’s Modbus/TCP interface. With a CVSS v4 base score of 6.9, the flaw is rated medium severity, but the practical risk is high because exploitation requires no privileges and is trivially achieved over any reachable network path.

Affected Products: An Exhaustive List

The advisory lists over 70 specific model numbers across the FX5U, FX5UC, FX5UJ, and FX5S families. For FX5U and FX5UC variants, firmware version 1.060 and later are affected; for all FX5UJ and FX5S models, every version—past, present, and future—remains vulnerable. This sweeping scope means that organizations cannot assume older firmware offers safety. Every MELSEC iQ-F CPU module in service must be inventoried immediately, with special attention paid to models where Mitsubishi has declared “all versions” affected.

The Vulnerability: Missing Authentication on Modbus/TCP

CVE-2025-7405 stems from a missing authentication for critical function (CWE-306). Modbus/TCP, an industrial protocol designed for a trusted factory floor, has no native authentication mechanism. When a PLC exposes its Modbus/TCP port directly or indirectly to broader networks, any actor who can reach that port can send read or write commands without providing credentials. In an iQ-F PLC, such writes can alter setpoints, flip outputs, or change internal variables that control physical processes. An attacker could also issue a command to stop program execution, halting production until an operator manually resets the device.

CISA’s advisory explicitly notes that successful exploitation can lead to information disclosure, information tampering, and denial of service. The attack complexity is low, requiring only network access and basic Modbus/TCP scripting skills. Researchers from OPSWAT’s Unit 515—Thai Do, Minh Pham, Quan Le, and Loc Nguyen—reported the issue to Mitsubishi Electric.

Why No Firmware Patch Is Coming

Mitsubishi Electric’s security advisory states clearly: “There are no plans to release a fixed version.” The vendor instead recommends network-level mitigations. This stance reflects the architectural difficulty of retrofitting authentication into a protocol that assumes a trusted environment. Introducing authentication could break interoperability with countless third-party supervisory systems and increase support burden. For defenders, this means the vulnerability is a permanent feature of the product line. Risk reduction hinges entirely on compensating controls.

Immediate Actions for Windows and OT Teams

For organizations where IT and operational technology (OT) converge on Windows-based management, a layered defense-in-depth approach is critical. The following steps, drawn from CISA guidance and community best practices, form a prioritized mitigation checklist.

1. Contain Exposure Immediately

  • Remove any internet-facing access. If a firewall rule allows inbound connections to the PLC’s Modbus/TCP port (default 502) or web management interface from the public internet, disable it at once.
  • Isolate PLCs behind a management VLAN. Place all affected devices in a dedicated network segment that only permits traffic from known SCADA servers, engineering workstations, and administrator jump hosts. Use ACLs to restrict communication strictly to required ports and IPs.
  • Enable the PLC’s IP filter function. The MELSEC iQ-F series includes an IP filter feature that allows only a whitelist of source IP addresses to communicate with the device. Refer to the FX5 User’s Manual, section 13.1, for configuration details. Lock down accepted IPs to the bare minimum of trusted management hosts.

2. Harden Remote Maintenance Pathways

Many attacks on ICS assets originate from compromised remote access channels. Force all remote maintenance through a dedicated, hardened jump host:
- Configure the jump host as a Windows Server or Windows 10/11 Enterprise workstation with full-disk encryption, AppLocker, and endpoint detection and response (EDR) enabled.
- Require multi-factor authentication (MFA) for login and VPN connection. Use an industrial VPN or a site-to-site VPN tunnel rather than exposing the PLC directly.
- Restrict jump host sessions to only the necessary Modbus/TCP and configuration ports. Log all sessions and feed logs to the SIEM.

3. Deploy Detection and Monitoring

Because the vulnerability lacks a patch, early detection of scanning or exploitation attempts becomes vital. Windows administrators should collaborate with OT engineers to implement SIEM rules that trigger on:
- Modbus/TCP connection attempts from IP addresses not in the authorized management list.
- Repeated write commands to unusual register ranges, especially outside maintenance windows.
- PLC program stop events coinciding with network traffic anomalies.
- Jump host logins at unexpected times or from unexpected source IPs.

Correlate these events with Windows Security Event Logs (Event ID 4624 for logon, 5156 for firewall connections) and VPN connection logs. Forward all relevant telemetry to a central SOC.

4. Plan for the Long Term

For critical assets where isolation cannot guarantee safety, develop a hardware replacement roadmap. Models marked “all versions” will never receive a firmware fix, and even if Mitsubishi changes its policy, a patch could take months to test and deploy. In the interim, consider adding physical safety overrides or redundant control loops to maintain safe operation if a PLC is compromised.

Notify all third-party maintenance vendors and system integrators of the new access restrictions. Update remote support contracts to require use of the managed jump host.

CISA’s Broader Recommendations

Beyond the vendor-specific mitigations, CISA urges all ICS asset owners to adopt proactive defense-in-depth strategies. These include:
- Segmenting IT and OT networks with firewalls and unidirectional gateways.
- Restricting physical access to control system equipment and the LAN segments they reside on.
- Employing application whitelisting and least privilege on Windows engineering workstations.
- Conducting regular vulnerability assessments and penetration tests on OT networks.

CISA also requests that organizations report any suspected malicious activity to help track potential broader exploitation.

Real-World Exploitability: Low Barrier, High Impact

The combination of a protocol with no authentication and a device that controls physical machinery creates a serious operational threat. Industrial environments have historically been slow to patch even when patches exist; here, with no patch available, the attack surface may persist for years. The fact that Modbus/TCP traffic is often allowed across firewalls for data collection by SCADA systems increases the risk that an attacker pivoting from a compromised IT workstation could reach the PLC.

Security researchers have long warned about the dangers of exposed Modbus/TCP interfaces. Shodan scans regularly turn up thousands of industrial devices with port 502 open to the internet. While CISA states that no public exploitation has been reported at this time, the low barrier to entry means that defending before a mass scanning campaign begins is imperative.

The Windows-OT Partnership in Practice

This vulnerability highlights why Windows IT teams must work closely with OT engineers. Network segmentation projects, firewall rule changes, and jump host deployments often require coordination between corporate IT, which manages Windows infrastructure, and plant operations, which owns the PLCs. Without a shared asset inventory and a jointly agreed security policy, mitigation measures can be incomplete or introduce availability risks.

Windows administrators can lead by ensuring that all management workstations and servers that interact with OT assets are fully patched, hardened against lateral movement, and monitored for suspicious behavior. They should also assist OT teams in setting up a robust logging pipeline from PLC-related network events into the SIEM.

Conclusion: Acceptance and Action

CVE-2025-7405 is not a vulnerability that will be patched away. It is a permanent feature of the MELSEC iQ-F product line’s Modbus/TCP implementation, and Mitsubishi Electric has made its posture clear. The only viable defense is a comprehensive network isolation and monitoring strategy, executed in tandem by Windows administrators and OT operators. Organizations that inventory their devices now, lock down network access, and deploy rigorous detection will be best positioned to weather any future exploitation attempts. The time to act is before the first exploit script appears on GitHub—not after.