Mitsubishi Electric CC-Link IE TSN flaw lets on-network attackers tamper with control data

CISA has published an updated industrial control systems advisory covering a message integrity weakness in Mitsubishi Electric’s CC-Link IE TSN communication protocol implementation, tracked as CVE-2026-13584 [1]. The flaw allows an attacker who can reach the same network segment as an affected device to tamper with communication data by sending specially crafted packets under specific timing conditions. The practical effect described by both CISA and the CVE record is interference with the device’s control function: a denial-of-service condition, or the device operating incorrectly [1].

The scope is the notable part. This is not a single-product bug. The CVE record lists affected classes running from MELSEC MX controllers and CC-Link IE TSN master/local modules through motion modules, remote I/O and converter modules, couplers, bridge modules, AC servo drives, inverters, an industrial robot controller network base card, the GOT3000 Series, Windows communication software, and several communication LSI development kits and SDKs. In other words, the weakness sits in the protocol handling that these products share, so it reaches both the controllers and the devices they talk to.

The advisory is marked Update A, meaning it revises an earlier release. What changed between revisions, and when the advisory was first issued, should be read from CISA’s advisory itself [1].

Who is affected

Anyone operating a CC-Link IE TSN network built on Mitsubishi Electric components should assume they are in scope until they have checked the advisory’s product table. CISA lists MELSEC MX Controller MX-R models MXR300-16, MXR300-32, MXR300-64, MXR500-128 and MXR500-256, and MX-F models MXF100-8-N32 and MXF100-8-P32, each with all versions affected [1]. The enumeration continues past that point, and the full list of affected models and versions should be taken from the CISA advisory and Mitsubishi Electric’s own notice rather than from this article.

The CVE record extends the affected families well beyond the MELSEC MX line — servo amplifiers, inverters, safety-capable remote modules and the GOT3000 Series are all named — which means a site can be exposed through field devices even if its controllers are not on the list.

How it works

The weakness class recorded against CVE-2026-13584 is improper enforcement of message integrity during transmission in a communication channel. Neither CISA nor the CVE record describes what the receiving device fails to check, so the internal mechanism is not something we can set out here. What the records do state is that an attacker with access to a CC-Link IE TSN network can tamper with communication data — the CVE record specifies control input and output values — by sending crafted packets under specific timing conditions [1]. The timing precondition is consistent with a race against the network’s scheduled cyclic communication rather than an arbitrary packet that works at any moment, though the sources do not spell out the timing window.

The CVSS 4.0 vector assigned to CVE-2026-13584 is AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N, scoring 7.1. That reads as: adjacent-network access required, no privileges, no user interaction, high impact to integrity and low impact to availability, with no loss of confidentiality. That profile matches the described behaviour — the attacker changes what the controller believes and what it commands, rather than reading secrets.

Adjacent-network access is the load-bearing precondition. Exploitation requires a foothold on, or a bridge into, the TSN segment itself. That is a meaningful barrier on a properly segmented plant network and almost none at all on a flat one, or on one reachable from a dual-homed engineering workstation.

There is no indication in the sources that this vulnerability has been exploited in the wild, and it does not appear in CISA’s Known Exploited Vulnerabilities catalogue. The sources also do not state whether fixed firmware or software versions exist, or what specific mitigations the vendor recommends; the affected versions are listed as “all” for the models visible in the advisory excerpt, so remediation guidance needs to come directly from Mitsubishi Electric.

What to do

• Open the CISA advisory [1] and work through the full product table against your asset inventory. The list is long and spans controllers, drives, I/O modules, operator terminals, software and SDKs — partial checks will miss devices.
• Confirm with Mitsubishi Electric whether a fixed version or an official mitigation exists for each affected model you run. The available sources do not identify patched versions.
• Verify that CC-Link IE TSN segments are isolated from business networks and from any internet-facing path. Adjacent-network access is the precondition for exploitation, so segmentation is the primary control here.
• Audit every device with a foot in both worlds: engineering laptops, jump hosts, historians, remote-access appliances and anything with a second NIC on the control segment.
• Restrict physical access to switch ports and cabinets on the TSN network. Injection requires being on the wire.
• Where integrity of control I/O matters for safety, review whether independent safety instrumented functions would detect and contain a device being driven with altered values.
• Add the affected asset classes to your monitoring scope so unexpected traffic patterns or unexplained control faults get investigated rather than reset.
• If you develop on the affected communication LSI DeviceKits or SDKs, check whether products you have shipped inherit the weakness and notify your own customers accordingly.