Mitsubishi Electric factory gear can be knocked offline by a single crafted network packet

Key points

• Mitsubishi Electric has confirmed a denial-of-service flaw, tracked as CVE-2025-3511, affecting more than 45 of its factory automation products worldwide.
• The bug carries a CVSS severity score of 7.5 out of 10 and sits in the Ethernet handling of CC-Link IE TSN and MELSEC iQ-series hardware.
• A single specially crafted UDP network packet can crash the device, and most affected models need a full power-cycle reset to come back.
• The gear is used in critical manufacturing sites globally, including plants run from Mitsubishi's home base in Japan.
• No user authentication is required to trigger the crash, so network segmentation is the main defence until firmware fixes land.

Mitsubishi Electric has warned that a large family of its factory floor equipment can be knocked offline by a single malformed network message. The advisory, republished by CISA (the US Cybersecurity and Infrastructure Security Agency), covers dozens of models used to run production lines, sensors and controllers inside factories.

The flaw is tracked as CVE-2025-3511. It sits in how the devices handle UDP, a common but connectionless way of sending small chunks of data across a network.

A remote attacker who can reach the device on the network can send one crafted UDP packet and cause a denial of service, meaning the equipment stops doing its job. On most affected models, the only way to recover is to physically reset the unit.

What actually goes wrong?

The devices fail to properly check the size of an incoming UDP packet, a weakness catalogued as CWE-1284. Feed them something they do not expect, and the Ethernet function locks up.

Mitsubishi describes three flavours of failure depending on the product. Some units hang outright and need a reset. Others suffer communication delays in what Mitsubishi calls Simple CPU communication, its shorthand for basic device-to-device messaging. A third group, the FX5-ENET and FX5-ENET/IP Ethernet modules, throws a timeout error during CC-Link IEF Basic communication but recovers on its own once valid packets start arriving again.

This is a pure availability bug. There is no data theft here, no code execution, no attacker sitting on the box afterwards. But in a factory, availability is the whole game. A remote I/O module that stops responding can halt a production line.

Which products are affected?

The list is long. It covers CC-Link IE TSN Remote I/O modules, analog-to-digital and digital-to-analog converter modules, FPGA modules, master and local station communication chips, MELSEC iQ-R series master/local and Ethernet interface modules, MELSEC iQ-F FX5 Ethernet modules, and the network portion of several MELSEC iQ-R CPU modules.

The vendor's advisory has the full model-by-model breakdown. If your plant runs anything with a CC-Link IE TSN or MELSEC iQ badge, check it against Mitsubishi's list rather than guessing.

Should plant operators be worried?

Yes, but the risk is manageable if the network is set up properly. This is a remote unauthenticated denial of service, so anything that stops a random UDP packet reaching the device closes off the attack.

Operational technology networks are not supposed to be reachable from the open internet in the first place. In practice, plenty are, whether through a forgotten VPN, a contractor's laptop, or a flat corporate network that touches the plant floor.

Mitsubishi's mitigation guidance is the usual industrial control system playbook: isolate control networks behind a firewall, restrict physical access, and only allow trusted hosts to talk to the affected modules. Would multi-factor authentication have helped here? Honestly, no. This is a protocol parsing bug, not a credential problem. Network segmentation is what matters.

Operators should watch Mitsubishi's product pages for fixed firmware and plan a maintenance window to apply it. Until then, treat any exposed UDP path to these devices as a live wire.