7 minhigh
Mitsubishi Electric Multiple FA Products (Update D) (CVE-2025-3511)
CVE-2025-3511 is a high-severity (CVSS 7.5) denial-of-service vulnerability in the Ethernet function of over 50 Mitsubishi Electric FA product models. A remote, unauthenticated attacker can send a specially crafted UDP packet to cause a DoS condition, timeout error, or communication delay. Most affected products require a system reset for recovery. Firmware updates are available for all affected products.
Conf:highAnalyzed:2026-08-27
Showing defanged values
- cveCVE-2025-3511Improper validation of specified quantity in input in the Ethernet function allows a remote attacker to cause a denial-of-service condition, timeout error, or communication delay by sending a specially crafted UDP packet.
Detection / Hunteropenrouter
What Happened
A security flaw was found in many Mitsubishi Electric industrial automation products. An attacker who can reach a vulnerable device over a network can send a specially crafted network message that causes the device to stop working, slow down, or lose its communication connection. Most affected devices need to be manually restarted to recover. Organizations using these products in manufacturing or industrial settings should update their device firmware and ensure the devices are protected by firewalls and not exposed to the internet.
Key Takeaways
- CVE-2025-3511 is a remote denial-of-service vulnerability (CVSS 7.5) in the Ethernet function of multiple Mitsubishi Electric FA products caused by improper validation of specified quantity in input (CWE-1284).
- A remote attacker can send a specially crafted UDP packet to cause a DoS condition, timeout error, or communication delay. Most affected products require a system reset for recovery.
- Over 50 product models are affected across CC-Link IE TSN Remote I/O modules, Analog-Digital Converter modules, Digital-Analog Converter modules, FPGA modules, Communication LSIs, MELSEC iQ-R Series, and MELSEC iQ-F Series.
- Firmware updates are available for all affected products. Mitsubishi Electric recommends firewall isolation, VPN use, LAN restriction, and physical access controls as mitigations.
Affected Systems
- Mitsubishi Electric CC-Link IE TSN Remote I/O modules (NZ2GN2S1, NZ2GN2B1, NZ2GNCF1, NZ2GNCE3, NZ2GN12A4, NZ2GN12A2, NZ2GN12A42 series) firmware <=09
- Mitsubishi Electric CC-Link IE TSN Analog-Digital Converter modules NZ2GN2S-60AD4, NZ2GN2B-60AD4 firmware <=07
- Mitsubishi Electric CC-Link IE TSN Digital-Analog Converter modules NZ2GN2S-60DA4, NZ2GN2B-60DA4 firmware <=07
- Mitsubishi Electric CC-Link IE TSN FPGA modules NZ2GN2S-D41P01, NZ2GN2S-D41D01, NZ2GN2S-D41PD02 firmware 01
- Mitsubishi Electric CC-Link IE TSN Remote Station Communication LSI CP620 NZ2GACP620-300, NZ2GACP620-60 firmware <=1.08J
- Mitsubishi Electric MELSEC iQ-R Series CC-Link IE TSN Master/Local Module RJ71GN11-T2 firmware <=26, RJ71GN11-EIP firmware <=10, RJ71GN11-SX firmware <=05
- Mitsubishi Electric MELSEC iQ-R Series Ethernet Interface Module RJ71EN71 firmware <=85
- Mitsubishi Electric CC-Link IE TSN master/local Station Communication LSI CP610 NZ2GACP610-60, NZ2KT-NPETNG51 firmware <=05
- Mitsubishi Electric MELSEC iQ-F Series FX5-CCLGN-MS firmware <=1.020, FX5-ENET firmware <=1.200, FX5-ENET/IP firmware <=1.106
- Mitsubishi Electric MELSEC iQ-R Series CPU modules R04ENCPU, R08ENCPU, R16ENCPU, R32ENCPU, R120ENCPU (Network Part) firmware <=85
Vulnerabilities (CVEs)
copy:
| CVE | Product | Severity | Description |
|---|---|---|---|
| CVE-2025-3511 | Mitsubishi Electric Multiple FA Products (CC-Link IE TSN modules, MELSEC iQ-R Series, MELSEC iQ-F Series) | High | Improper validation of specified quantity in input in the Ethernet function allows a remote attacker to cause a denial-of-service condition, timeout error, or communication delay by sending a specially crafted UDP packet. |
Attack Chain
- Reconnaissance: Attacker identifies Mitsubishi Electric FA products accessible on the network via Ethernet
- Initial Access: Attacker sends a specially crafted UDP packet to the target device's Ethernet function
- Impact: The malformed UDP packet triggers improper input validation, causing a denial-of-service condition, timeout error, or communication delay
- Persistence of Impact: Most affected products require a manual system reset to restore normal operation
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No detection rules or queries are provided in the advisory. The advisory is a vendor/CISA vulnerability disclosure with remediation and mitigation guidance only.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | None | The vulnerability targets network functions of embedded industrial controllers and I/O modules. These devices do not run standard operating systems monitored by EDR agents. |
| Network Visibility | Medium | Network monitoring tools could detect anomalous UDP traffic directed at affected devices. However, the advisory does not provide specific packet signatures or payload characteristics for the crafted UDP packet. |
| Detection Difficulty | Hard | The advisory does not describe the specific structure of the crafted UDP packet. Defenders would need to develop their own network signatures based on protocol analysis of CC-Link IE TSN traffic. Distinguishing malicious UDP packets from legitimate industrial traffic requires deep protocol understanding. |
Required Log Sources
- Network firewall logs (UDP traffic to affected device ports)
- ICS/OT network traffic monitoring (PCAP or flow data)
- Device syslog or diagnostic logs for DoS/timeout events
- Network IDS/IPS alerts for anomalous UDP patterns
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for unexpected UDP traffic from non-industrial network segments directed at Mitsubishi Electric FA device IP addresses. If you have visibility into ICS network traffic via a passive OT monitor or SPAN port, look for UDP packets that do not match expected CC-Link IE TSN communication patterns. | Network flow data, firewall logs, OT network IDS alerts | Initial Access / Impact | Medium — legitimate industrial communication uses UDP and may originate from various network segments depending on architecture. |
| Consider hunting for repeated device resets or communication timeout events on affected Mitsubishi Electric modules. If you have access to device diagnostic logs or SCADA communication loss alerts, correlate these with network traffic spikes. | Device diagnostic logs, SCADA/HMI alarm logs, network monitoring alerts | Impact | Medium — communication timeouts and device resets can occur from network misconfiguration, power events, or legitimate maintenance. |
Control Gaps
- Standard IT network IDS/IPS may lack signatures for CC-Link IE TSN protocol anomalies
- EDR agents cannot be deployed on embedded industrial controllers and I/O modules
- Firewall rules permitting UDP traffic to affected devices may not distinguish legitimate from malicious packets without deep packet inspection
Key Behavioral Indicators
- Anomalous UDP packets directed at CC-Link IE TSN device IP addresses from unexpected source IPs
- Sudden communication loss or timeout errors on MELSEC iQ-R or iQ-F series modules
- Unscheduled device resets on affected Mitsubishi Electric FA products
- UDP traffic patterns that do not conform to expected CC-Link IE TSN protocol behavior
False Positive Assessment
Medium — Detecting the crafted UDP packet requires distinguishing it from legitimate CC-Link IE TSN UDP traffic. Communication timeouts and device resets can also result from non-malicious causes such as network misconfiguration or power events.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider identifying all instances of affected Mitsubishi Electric FA products in your environment and prioritizing firmware updates based on network exposure.
- Consider restricting network access to affected devices by ensuring firewalls block UDP traffic from untrusted networks and hosts. If applicable, isolate affected devices within a dedicated LAN segment.
- If remote access to affected devices is required, evaluate whether a VPN can be used to restrict access to authenticated users only.
Infrastructure Hardening
- Consider implementing network segmentation to separate ICS/OT networks from business networks, ensuring affected devices are not accessible from the internet.
- Evaluate deploying ICS-aware network monitoring or IDS/IPS capable of inspecting CC-Link IE TSN traffic for anomalies.
- Consider restricting physical access to affected products and the LANs to which they are connected.
User Protection
- Consider installing and maintaining anti-virus software on PCs that can access affected products, as recommended by the vendor.
- Evaluate whether maintenance workstations connected to affected devices have up-to-date endpoint protection.
Security Awareness
- Consider incorporating ICS vulnerability management into existing awareness programs, emphasizing the importance of timely firmware updates for industrial devices.
- If applicable, ensure OT engineering teams are aware that a system reset is required for recovery if a DoS condition occurs on affected products.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping2 techniques
