CVE-2025-5241: MELSEC iQ-F Auth Bypass Vulnerability

CVE-2025-5241 Overview

CVE-2025-5241 is an overly restrictive account lockout vulnerability affecting Mitsubishi Electric Corporation MELSEC iQ-F Series programmable logic controllers (PLCs). A remote unauthenticated attacker can repeatedly submit invalid login attempts to trigger the lockout mechanism against legitimate users. Once triggered, valid operators cannot authenticate until the lockout timer expires or the product is reset. The weakness maps to [CWE-645: Overly Restrictive Account Lockout Mechanism] and represents a denial of service condition against industrial control system (ICS) operators.

Critical Impact
Attackers on the network can lock legitimate engineers out of MELSEC iQ-F PLCs, disrupting operational visibility and maintenance access until the device is reset.

Affected Products

Mitsubishi Electric MELSEC iQ-F Series programmable logic controllers
See Mitsubishi Electric Vulnerability Report 2025-005 for the complete list of affected models and firmware versions
See CISA ICS Advisory ICSA-25-184-04 for deployment context

Discovery Timeline

2025-07-11 - CVE-2025-5241 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-5241

Vulnerability Analysis

The vulnerability resides in the authentication component of MELSEC iQ-F Series PLCs. The account lockout policy triggers after repeated failed login attempts without differentiating between legitimate user error and adversarial probing. An unauthenticated remote attacker can weaponize the protection mechanism itself to deny service to authorized operators.

Because the target devices are PLCs deployed in operational technology (OT) environments, loss of authenticated access blocks routine engineering tasks. Operators cannot push logic changes, retrieve diagnostic data, or perform configuration updates during the lockout window. Recovery requires either waiting for the timeout period or performing a device reset, which itself can disrupt production workflows.

The attack requires only network reachability to the PLC's authentication interface. No prior credentials, user interaction, or elevated privileges are needed.

Root Cause

The underlying flaw is a design decision in the authentication logic: the lockout mechanism does not distinguish attempts originating from the legitimate user versus attempts originating from unauthorized network sources. There is no source-based throttling, no CAPTCHA-style challenge, and no differentiated lockout policy for known versus unknown clients. Any actor able to reach the login endpoint can enumerate usernames and force lockouts.

Attack Vector

An attacker with network access to the PLC repeatedly submits authentication requests using target usernames and deliberately incorrect passwords. After crossing the failed-attempt threshold, the account is locked. Repeating the process across multiple user accounts can effectively deny administrative access to the entire device. No exploit code is required beyond a standard authentication client capable of speaking the MELSEC protocol. No public proof-of-concept exploit is currently listed in Exploit-DB or CISA KEV.

Detection Methods for CVE-2025-5241

Indicators of Compromise

Bursts of failed authentication events on MELSEC iQ-F Series PLCs originating from a single or small set of source IP addresses
Multiple user accounts entering a locked state within a short time window
Unexpected authentication traffic to PLCs from hosts outside the engineering workstation subnet
Legitimate operator reports of inability to log in shortly after unrelated network activity

Detection Strategies

Correlate authentication failure logs across MELSEC iQ-F devices to identify coordinated lockout patterns
Baseline normal engineering-station-to-PLC traffic and alert on deviations in source, volume, or timing
Monitor ICS network segments for MELSEC protocol traffic originating from non-engineering hosts
Alert when multiple distinct accounts on the same PLC transition to a locked state within a defined window

Monitoring Recommendations

Forward PLC authentication and system logs to a centralized SIEM or historian for correlation
Deploy passive ICS network monitoring to inspect MELSEC authentication attempts without impacting the control loop
Track lockout duration and reset events as high-priority operational metrics
Review firewall and access control logs at the IT/OT boundary for unexpected connections to PLC management ports

How to Mitigate CVE-2025-5241

Immediate Actions Required

Restrict network access to MELSEC iQ-F Series PLCs so that only authorized engineering workstations can reach authentication interfaces
Place affected PLCs behind firewalls and within isolated OT network segments consistent with the Purdue model
Require VPN or jump-host access for any remote engineering session that touches PLCs
Review the Mitsubishi Electric Vulnerability Report 2025-005 for vendor-specific remediation guidance

Patch Information

Refer to Mitsubishi Electric Vulnerability Report 2025-005 for the authoritative list of affected firmware versions and any available fixed releases. CISA ICS Advisory ICSA-25-184-04 provides additional mitigation guidance for ICS operators.

Workarounds

Enforce network segmentation between corporate IT and OT networks to limit exposure of PLC authentication interfaces
Apply strict allow-lists on ICS firewalls so that only known engineering hosts can initiate MELSEC sessions
Establish documented procedures for rapid PLC reset when a lockout event impacts production
Follow CISA guidance for defense-in-depth strategies described in ICSA-25-184-04

bash

# Example: restrict inbound access to MELSEC iQ-F PLCs at the OT firewall
# Replace addresses with your engineering-workstation subnet and PLC IPs
iptables -A FORWARD -s 10.10.20.0/24 -d 10.20.30.0/24 -p tcp --dport 5007 -j ACCEPT
iptables -A FORWARD -d 10.20.30.0/24 -p tcp --dport 5007 -j DROP