Mitsubishi Electric has disclosed a cluster of high‑impact denial‑of‑service vulnerabilities affecting the MELSEC iQ‑F Series EtherNet/IP and Ethernet modules that, if left unmitigated, can be weaponized by a remote attacker to render communications unavailable and force a device reset — with one flaw already fixed for a specific module version and others still pending or intentionally unpatched. (
mitsubishielectric.com)
Overview
The vendor advisory released on March 3, 2026, documents three related DoS issues assigned CVE‑2026‑1874, CVE‑2026‑1875, and CVE‑2026‑1876. All three are network‑accessible weaknesses that allow an unauthenticated remote actor to induce uncontrolled receive‑buffer consumption by
repeatedly sending UDP packets to affected products, ultimately requiring a manual or remote system reset to recover. The three CVEs carry high CVSS v4 base scores (8.7) in Mitsubishi Electric’s report. (
mitsubishielectric.com)
These vulnerabilities affect two classes of MELSEC iQ‑F communication modules in different ways:
- FX5‑ENET/IP (EtherNet/IP module): CVE‑2026‑1874 affects FX5‑ENET/IP versions 1.106 and prior; CVE‑2026‑1876 affects FX5‑ENET/IP (all versions) and — according to the vendor — has no plan for a fixed firmware (mitigations only). (mitsubishielectric.com)
- FX5‑EIP (EtherNet/IP module branded FX5‑EIP): CVE‑2026‑1874 and CVE‑2026‑1875 impact FX5‑EIP (all versions); Mitsubishi states fixes for the FX5‑EIP are scheduled but not yet released at time of the advisory. (mitsubishielectric.com)
Independent vulnerability trackers and security researchers have mirrored the vendor’s findings and reflected similar severity assessments and exploit vectors, confirming the consensus that these are remotely exploitable DoS conditions caused by UDP packet flooding and resource‑handling bugs.
Background
MELSEC iQ‑F is Mitsubishi Electric’s compact PLC platform widely deployed in manufacturing and industrial automation. The platform supports a range of communications modules — including
FX5‑ENET/IP and
FX5‑EIP — which provide EtherNet/IP connectivity for higher‑level controllers, HMIs, and I/O networks. These communication modules are often placed at network edges and in control racks where stability of Ethernet connectivity is mission‑critical.
Industrial control product families such as MELSEC iQ‑F have a long history of periodic security disclosures and multiple advisories over the past years addressing communication‑stack weaknesses, authentication issues, and resource‑exhaustion flaws; vendors and national CERTs have repeatedly warned operators to treat network‑accessible management and protocol stacks as high‑risk attack surfaces.
Technical details
What the vulnerabilities are
The vendor’s advisory summarizes three DoS variants:
- CVE‑2026‑1874 — Always‑Incorrect Control Flow Implementation (CWE‑670): A logic/control‑flow flaw that leads to an incorrect state in packet handling, allowing an attacker to repeatedly feed UDP packets and cause the module to consume receive buffers without recovering. Affected: FX5‑ENET/IP versions 1.106 and prior and FX5‑EIP (all versions). Recovery requires a system reset. (mitsubishielectric.com)
- CVE‑2026‑1875 — Improper Resource Shutdown or Release (CWE‑404): A resource‑release bug in the packet handling code that can leave resources in a consumed/held state, causing buffer exhaustion and DoS; a fixed version for some modules is planned. (mitsubishielectric.com)
- CVE‑2026‑1876 — Improper Resource Shutdown or Release (CWE‑404): Similar to CVE‑2026‑1875 but documented by the vendor as affecting FX5‑ENET/IP (all versions); Mitsubishi explicitly says no fixed firmware will be released for this particular issue and operators must rely on mitigations. (mitsubishielectric.com)
The common exploitation pattern is simple: an unauthenticated actor sends a sustained stream of UDP packets crafted to trigger the affected receive‑path logic. The modules fail to reclaim or correctly manage buffer resources; buffers fill and legitimate network traffic is dropped. The devices continue to operate internally but the Ethernet function is disrupted until a reset. The vendor classifies the impact as availability only (DoS) — there is no vendor evidence in the advisory of code execution or confidentiality/integrity compromises — but availability loss in OT networks can have immediate physical and business consequences. (
mitsubishielectric.com)
Confirmations and independent notes
Security trackers and vulnerability aggregators reproduced the vendor’s summary, assigned public CVE identifiers, and scored the issues as high severity consistent with remote, unauthenticated network attacks. Multiple independent sources also call out the UDP‑based vector and the requirement for device reset after exploitation. These secondary sources provide an independent corroboration of Mitsubishi’s findings.
Impact and risk assessment
For OT environments
- Availability risk is immediate. If an attacker can reach the module over the network, they can disrupt communications between PLCs, HMIs, and other controllers, halting data flows used by process control loops. Many processes depend on continuous Ethernet connectivity; even short outages can trigger alarms, stop conveyors, or create product loss.
- Recovery requires manual or remote reset. A complete remediation of the device’s network function requires resetting the affected module, which in many plants may mean stopping production or executing controlled failovers.
- Attack surface depends on network exposure. Modules reachable from enterprise networks, remote maintenance links, or the internet are at highest risk. Modules isolated inside segregated OT networks are less exposed but still vulnerable if firewall rules or jump hosts are misconfigured. (mitsubishielectric.com)
For security teams and risk owners
- Exploit complexity is low. The research and vendor assessment identify no authentication or complex preconditions; the attacker only needs network reachability to the affected UDP port(s), making opportunistic scans and exploitation straightforward.
- Potential for accidental DoS is nontrivial. Misconfigured test tools, diagnostic traffic, or legitimate monitoring could inadvertently trigger the same buffer exhaustion in vulnerable firmware — a caution for engineers running network scans or aggressive polling against older modules.
Exploitation in the wild
As of the publication of Mitsubishi Electric’s advisory, there is no public evidence in the vendor advisory that these issues are being widely exploited in the wild. Independent aggregators have not yet published confirmed incident reports attributing outages to these CVEs. That said, the low bar for exploitation and the public disclosure of the vulnerability details increase the chance of scanning and opportunistic attacks following the advisory. Security teams should therefore assume a moderate to high likelihood of targeted or opportunistic scanning against vulnerable assets. (
mitsubishielectric.com)
What Mitsubishi fixed — and what remains
- Fixed: For CVE‑2026‑1874, Mitsubishi has released firmware FX5‑ENET/IP version 1.107 or later to address the Always‑Incorrect Control Flow Implementation issue for FX5‑ENET/IP. Operators using FX5‑ENET/IP should upgrade to 1.107 or later. (mitsubishielectric.com)
- Planned fixes: For FX5‑EIP, Mitsubishi indicates that a fixed firmware is scheduled for release in the near future for the vulnerabilities that affect that module; operators must monitor vendor communications to obtain and apply the update when it becomes available. (mitsubishielectric.com)
- No fix planned: For CVE‑2026‑1876, the vendor states that no fixed version will be released for FX5‑ENET/IP for that variant; mitigations and workarounds are the only recourse. This is a critical operational decision by the vendor and significantly affects long‑term risk posture for modules that remain in the field. (mitsubishielectric.com)
Mitigations and recommended immediate actions
Operators should treat these as urgent and follow a prioritized remediation and mitigation plan. Below is a practical playbook.
1. Immediate triage (0–24 hours)
- Identify and inventory all installed MELSEC iQ‑F FX5‑ENET/IP and FX5‑EIP modules across your environment. Record firmware versions and which devices are reachable from enterprise or remote networks. Use vendor manuals for firmware version checks. (mitsubishielectric.com)
- Isolate exposed modules where possible. If a module is directly reachable from untrusted networks (including remote maintenance links or the Internet), immediately restrict access at the perimeter firewall or VPN gateway. Prioritize those modules for mitigation. (mitsubishielectric.com)
- Apply temporary access controls: block UDP traffic destined for the module’s Ethernet interface unless strictly required for legitimate communication. At minimum, deny UDP from untrusted subnets. Use firewall rules on industrial firewalls or switch ACLs to accomplish this. (mitsubishielectric.com)
2. Patching and vendor fixes (24–72 hours)
- Update FX5‑ENET/IP modules to firmware 1.107 or later where available. Follow Mitsubishi’s recommended update procedure in the MELSEC iQ‑F FX5 User’s Manual (Application) and use the vendor download portal for the firmware package. Test updates in a lab or maintenance window before rolling into production. (mitsubishielectric.com)
- Monitor Mitsubishi communications for the announced FX5‑EIP fix and plan for staged deployment once the vendor release is available. Do not delay testing. (mitsubishielectric.com)
3. Compensating controls where patching is not possible
- Network segmentation: Keep all affected products inside a protected OT VLAN with strict filtering; block access from enterprise and Internet networks unless tunneled over a vetted VPN. (mitsubishielectric.com)
- IP filtering on the module: Use the module’s IP filter function to whitelist trusted hosts only and block others. Mitsubishi’s manuals document the IP filter configuration ability. (mitsubishielectric.com)
- Restrict physical access: Ensure devices and connected network equipment are physically secured to minimize the chance of an attacker gaining on‑site access. (mitsubishielectric.com)
- Use VPNs / jump hosts for remote maintenance: If remote access is required, require connections through an authenticated, monitored VPN or a hardened jump host; do not expose the module to the public internet. (mitsubishielectric.com)
- Intrusion detection and rate limiting: On segmentation devices, implement UDP rate limiting toward PLC modules and enable IDS/IPS signatures that detect floods or anomalous UDP traffic volumes. Consider simple blackholing for hosts that generate flood traffic.
4. Longer‑term actions (weeks to months)
- Replace modules where vendor declines to fix: For devices affected by CVE‑2026‑1876 where no fix is planned, evaluate replacement with a fixed module or redesign connectivity so the module is not reachable from any untrusted network segment. This may require procurement and scheduled downtime planning. (mitsubishielectric.com)
- Harden network architecture: Review and strengthen OT/IT separation, implement zero‑trust principles where feasible, and ensure remote maintenance uses just‑in‑time access with strong authentication and logging.
- Patch management and asset lifecycle: Incorporate this event into vendor‑selection and lifecycle planning processes; avoid running unfixable or end‑of‑life communications modules in high‑risk zones.
Detection and monitoring: how to tell if you’ve been targeted
- Monitor device telemetry and network statistics: Repeated spikes of UDP packets to the module’s IP from one or multiple external hosts, especially sustained traffic consuming receive buffers, is the classic signature of the documented attack.
- Look for communication outages: Sudden loss of Ethernet communication to modules or persistent packet drops that are resolved only after device reset is a strong indicator of exploitation of these vulnerabilities. (mitsubishielectric.com)
- Network flow analysis: Collect NetFlow/sFlow and use detection rules to flag high‑rate UDP to the module IPs or unusual UDP ports that are not part of normal operations.
- Host‑level logs: Where available, capture module logs and engineering tool diagnostics that report buffer or resource exhaustion conditions.
- Correlate with external scanning: Many opportunistic attackers scan broad IP ranges. If you see inbound scanning activity immediately prior to a DoS incident, correlate with packet captures to determine intent and pattern.
Operational checklist: step‑by‑step (concise)
- Inventory all FX5‑ENET/IP and FX5‑EIP modules and record versions. (mitsubishielectric.com)
- If FX5‑ENET/IP is running ≤ 1.106, schedule immediate upgrade to 1.107 (test first). (mitsubishielectric.com)
- For FX5‑EIP, apply vendor mitigations until firmware is released. (mitsubishielectric.com)
- Block UDP from untrusted networks to module addresses; limit management access to vetted jump hosts/VPNs. (mitsubishielectric.com)
- Implement UDP rate limits and IDS alerts for ano6. If a device is exposed and cannot be patched or mitigated, prepare an asset replacement and isolation plan. (mitsubishielectric.com)
Why this matters — a strategic analysis
These vulnerabilities underscore perennial weaknesses in OT product lifecycles and network exposure:
- Protocol handling continues to be a high‑risk vector. Industrial communication stacks are complex and historically under‑resourced for security testing; even simple UDP packet patterns can trigger resource leaks or logic errors that produce outages. The vendor’s multiple CVEs for similar resource handling problems make this point tangible. (mitsubishielectric.com)
- Vendor patch insurance varies by product. Mitsubishi’s decision to release a fix for FX5‑ENET/IP (1.107) but not for one of the variants (CVE‑2026‑1876) highlights a reality many operators face: not all product families receive the same lifecycle investment. That makes asset inventory and end‑of‑life planning essential to risk management. (mitsubishielectric.com)
- Network exposure and remote maintenance are persistent risks. Many control networks have been bridged to enterprise or remote service paths for convenience. Those same bridges multiply risk when fundamental protocol bugs are publicly disclosed. The recommended mitigations — VPNs, segmentation, IP filtering — are necessary but operationally burdensome; organizations should budget for and institutionalize them. (mitsubishielectric.com)
- The OT threat timeline is compressed after disclosure. When an advisory and technical details are public, scanning and exploitation attempts typically rise quickly; operators must therefore treat public disclosure as a trigger event to accelerate mitigations and monitoring. Independent trackers and vulnerability databases already have public records for these CVEs, increasing the chance of opportunistic scanning.
Case notes from the field (what we’ve seen in community reporting)
Operational forums and industrial security threads are full of prior MELSEC incidents — ranging from web‑server length handling DoS to account lockout and Modbus/TCP weaknesses — that show how small communication quirks can produce outsized operational impacts. These historical reports make clear that even “availability‑only” vulnerabilities can produce cascading problems when controllers are placed in the wrong network context. These community discussions are part of the reason many responders treat these disclosures as urgent.
Practical recommendations for Windows and IT teams that support OT
- Ensure Windows jump hosts and engineering workstations that access PLCs have up‑to‑date endpoint protection and are restricted to the minimal set of network ports and addresses. Attackers sometimes pivot from a compromised IT host into OT networks. (mitsubishielectric.com)
- Use host‑based firewalls and strict segmentation on Windows machines used for maintenance; the fewer exposed machines, the smaller the attack surface.
- Maintain a searchable CMDB/asset register mapping firmware versions to physical devices; this enables you to find all affected devices quickly when advisories arrive. The vendor’s manual pages and firmware‑version checks must be part of your asset validation process. (mitsubishielectric.com)
What to watch for next
- Vendor updates for FX5‑EIP: Mitsubishi announced a forthcoming fix; operators should sign up for vendor PSIRT notifications and plan tested rollouts. (mitsubishielectric.com)
- Threat activity indicators: Watch for public reports of active exploitation, proof‑of‑concept code, or exploit scanning tied to these CVEs. Early indications would likely show sudden UDP floods toward industrial IP ranges.
- Inventory and replacement planning: For modules where no fix will be provided, begin procurement planning and risk acceptance documentation; unfixable code paths in network stacks are high‑bias items for replacement. (mitsubishielectric.com)
Conclusion
Mitsubishi Electric’s advisory about multiple denial‑of‑service vulnerabilities in the MELSEC iQ‑F FX5 Ethernet/EtherNet‑IP modules is a timely reminder that
network reachability equals risk in OT environments. The good news is that a measured, prioritized response — inventory, isolation, patching of FX5‑ENET/IP to
1.107 or later, and layered mitigations for modules still awaiting or not receiving fixes — will dramatically reduce exposure. The less comfortable truth is that vendor patching policies are heterogeneous; where a fix is not planned, long‑term risk reduction requires architectural changes, replacement planning, and stricter network controls.
Treat the advisory as an operational imperative: locate affected modules now, apply the vendor’s fixed firmware where available, immediately harden access for modules without fixes, and assume adversaries will scan for vulnerable devices. The combination of straightforward exploitation vectors and the potential for production outages makes this a leading candidate for immediate remediation and monitoring across industrial estates. (
mitsubishielectric.com)
Source: CISA
Mitsubishi Electric MELSEC iQ-F Series EtherNet/IP module and Ethernet module | CISA