CVE-2025-7731: MELSEC iQ-F Information Disclosure Flaw

CVE-2025-7731 Overview

CVE-2025-7731 is a cleartext transmission of sensitive information vulnerability [CWE-319] affecting Mitsubishi Electric MELSEC iQ-F Series CPU modules. The flaw resides in the handling of SLMP (SeamLess Message Protocol) communication, where authentication credentials traverse the network without encryption. A remote, unauthenticated attacker positioned to intercept SLMP traffic can capture these credentials. With the stolen credentials, the attacker can read or write device values on the programmable logic controller (PLC) and halt program execution. The vulnerability impacts industrial control system (ICS) environments where MELSEC iQ-F controllers govern automation processes.

Critical Impact

Network-based interception of SLMP traffic exposes PLC credentials, enabling unauthorized read/write operations and program shutdown on industrial control devices.

Affected Products

• Mitsubishi Electric MELSEC iQ-F Series CPU modules (per vendor advisory 2025-012)
• Devices using SLMP communication for engineering or HMI access
• Industrial control deployments exposing SLMP traffic to untrusted networks

Discovery Timeline

• 2025-09-01 - CVE-2025-7731 published to the National Vulnerability Database (NVD)
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-7731

Vulnerability Analysis

The MELSEC iQ-F CPU module exchanges authentication data over SLMP without applying transport-layer encryption. SLMP is an open, application-layer protocol used to interact with Mitsubishi PLCs for device monitoring, programming, and diagnostics. Because credential material is encoded in cleartext within SLMP request frames, any adversary with passive access to the network segment can extract it using standard packet capture tools. The attack does not require authentication, user interaction, or elevated privileges, and it can be performed entirely over the network. Once credentials are obtained, the attacker can authenticate to the PLC as a legitimate engineering client and issue device-level commands. These commands include reading data registers, writing arbitrary values, and stopping running ladder logic programs. The integrity of physical processes controlled by the PLC depends on this credential remaining confidential.

Root Cause

The root cause is the absence of encryption on the SLMP authentication exchange. The protocol implementation transmits credential fields in plaintext rather than wrapping the session in TLS or applying challenge-response authentication. This design decision violates the secure transmission principle described in CWE-319: Cleartext Transmission of Sensitive Information.

Attack Vector

An attacker on the same broadcast domain, on a transit path, or in control of a compromised network device can sniff SLMP packets between an engineering workstation and the CPU module. After harvesting credentials, the attacker replays them in a new SLMP session against the target PLC. Successful authentication grants the attacker the same operational privileges as the legitimate engineer, including the ability to write device values or issue a STOP instruction to the running program. Detailed exploitation mechanics are described in the Mitsubishi Electric Vulnerability Report and the CISA ICS Advisory ICSA-25-240-02.

No verified public proof-of-concept code is available for CVE-2025-7731.
Refer to the vendor advisory and CISA bulletin for protocol-level details.

Detection Methods for CVE-2025-7731

Indicators of Compromise

• Unexpected SLMP sessions originating from hosts that are not approved engineering workstations or HMI servers.
• PLC operating mode transitions from RUN to STOP outside of scheduled maintenance windows.
• Device value writes to registers from source IP addresses absent from the asset inventory.
• Repeated SLMP authentication attempts from a single source within a short interval, suggesting credential replay.

Detection Strategies

• Deploy ICS-aware network intrusion detection that parses SLMP and alerts on authentication frames containing cleartext credentials.
• Baseline normal SLMP client-to-PLC pairings and flag any new client establishing sessions with the MELSEC iQ-F.
• Correlate PLC program-state change events with authenticated SLMP commands to identify unauthorized STOP operations.

Monitoring Recommendations

• Mirror traffic from OT switches connected to MELSEC iQ-F controllers into a passive monitoring sensor.
• Log all SLMP command transactions, including source address, command code, and target device range, to a centralized SIEM.
• Monitor span ports for ARP spoofing or rogue DHCP activity that could indicate an adversary preparing a man-in-the-middle position.

How to Mitigate CVE-2025-7731

Immediate Actions Required

• Apply the firmware updates and configuration guidance published in Mitsubishi Electric advisory 2025-012.
• Restrict SLMP access to approved engineering workstations using firewall rules or access control lists at the cell or zone boundary.
• Rotate any credentials previously used over untrusted networks, since they may already be exposed.
• Place MELSEC iQ-F controllers on dedicated OT VLANs isolated from corporate and internet-facing networks.

Patch Information

Mitsubishi Electric has published vendor guidance in advisory 2025-012. Review the Mitsubishi Electric Vulnerability Report, the CISA ICS Advisory ICSA-25-240-02, and the JVN Vulnerability Report for the current list of fixed versions and recommended countermeasures.

Workarounds

• Tunnel SLMP communication through an IPsec or TLS-protected VPN between engineering hosts and the PLC zone.
• Enable the IP filter function on the CPU module to allow connections only from specific source IP addresses.
• Disable SLMP on Ethernet ports that do not require remote engineering access.
• Use a unidirectional gateway or data diode where SLMP data must leave the OT zone for historian or monitoring purposes.

# Example firewall restriction limiting SLMP (TCP/UDP 5007 default) to one engineering host
iptables -A FORWARD -p tcp -s 10.10.20.15 -d 10.20.30.40 --dport 5007 -j ACCEPT
iptables -A FORWARD -p tcp -d 10.20.30.40 --dport 5007 -j DROP