Picture a substation. The device that carries breaker positions, line currents and alarms to the control center is an RTU. It has run without trouble for years; nobody touches it, because touching it means cutting telecontrol and running the substation on local control for a while.
On 6 October 2026, CISA published an advisory for this device family. One of the vulnerabilities on the list carries the identifier CVE-2010-2965. A vulnerability numbered sixteen years ago is being announced again for a device in the field today. CISA, ICSA-26-279-06
This advisory raises a practical question: why do OT devices live this long, and how do we cope in the field with a device that has no patch?
An RTU (Remote Terminal Unit) collects measurements at a remote point such as a substation or pump station, sends them to the central SCADA system and passes commands from the center to the field. It runs embedded software called firmware; in many RTUs that firmware sits on top of a real-time operating system such as VxWorks. A CVE is the identifier given to a known security vulnerability; the 2010 in CVE-2010-2965 is the year it was numbered. EOL (end of life) means the manufacturer no longer produces updates and patches for a product.
What does the advisory say?
The advisory covers versions 11.x and earlier of the communication unit (CMU) firmware in Hitachi Energy's RTU500 series. The manufacturer has declared these versions end of life. Dragos reported the vulnerabilities. The list contains two critical items from 2026: firmware upload and directory-traversal file writing without authentication. There is also an authorization flaw that lets an authenticated user trigger a reboot, alongside three much older records: a VxWorks debug service from 2010, unauthenticated command execution from 2014 and code download without an integrity check from 2023. CISA, ICSA-26-279-06
The manufacturer's wording is worth noting: the findings "do not affect currently supported RTU500 CMU firmware versions"; however there is "a likelihood" that the end-of-life versions are affected, and those versions "are no longer maintained with security updates." The recommended fix is to move to 12.7.8, 13.9.1 or the latest release. CISA, ICSA-26-279-06
The recommendation is to move to a supported firmware branch. In the field, that requires planning the major version transition and checking compatibility with the existing configuration.
What was the 2010 vulnerability?
VxWorks is a real-time operating system widely used in embedded devices. While testing the software on a device, developers use a debugging tool: the WDB agent. This agent listens on UDP port 17185 and allows reading and writing the device's memory and calling functions. On a development bench it is very useful. Left enabled on a production device, it is a back door for anyone who can reach the RTU over the network: a computer on the station LAN, a connection from the central WAN, or a line opened for maintenance.
The US ICS-CERT announced this in 2010. The recommendation was two lines long: vendors should disable the debug agent for production systems; users should restrict access to port 17185/udp with firewall rules. CISA, ICSA-10-214-01
Sixteen years later: same advice, same port, same mechanism. Today's advisory says this service is used "on few of the Hitachi Energy RTU500 CMU firmware legacy versions." So not all old versions; but we cannot know which ones without checking the firmware in the field. CISA, ICSA-26-279-06
What does normal traffic look like?
What does normal RTU communication look like? I decoded an IEC 60870-5-104 general interrogation between a control center and an RTU with TShark.
One operation the center performs is say "report your whole current status"; this is called a general interrogation. The decode looks like this:
IEC 60870-5 ASDU <- I ASDU=1 C_IC_NA_1 Act IOA=0
TypeId: C_IC_NA_1 (100)
CauseTx: Act (6)
QOI: Station interrogation (global) (20)
IEC 60870-5 ASDU -> I ASDU=1 C_IC_NA_1 ActCon IOA=0
CauseTx: ActCon (7)
Enlarge details
This is the traffic we allow to the RTU through the firewall: port 2404, known ASDU types, a predictable exchange with the center. The VxWorks debug service (17185/udp) from the previous section is not part of this conversation; it is a separate door sitting on the same device, one that should be closed. Knowing what a device "should be talking" is the first step to closing off what it "should not." When the table below mentions a firewall rule, this is exactly the distinction it means.
This example was also built with scapy and decoded from file with TShark 4.2.2.
Why is it still in the field?
Someone coming from IT asks, "why didn't you update?" The question is fair, and it has an answer.
Enlarge details
For a substation or a production line, the device is less like software and more like plumbing. Several reasons stack up:
- The outage window. Updating the RTU means cutting the substation's telecontrol and switching to local control; if the RTU also runs interlocking or automation logic, the job grows. That window opens once a year, sometimes once every three years.
- The verification burden. You have to prove that the new firmware works the same way with the protection relays, the SCADA protocol and the local logic. "We updated it and it seems to work" is not accepted.
- The major version jump. The fix in the advisory is moving from 11.x to 12.x or 13.x. That often means rebuilding the configuration, sometimes replacing hardware.
- Ownership. The integrator who installed the device may be gone; the engineer who knew the project may have retired. Behind the fear of touching it there is usually lost knowledge.
That is why a twenty-year-old device is normal in OT. Even when the NCSC's August 2026 guidance says "replace boundary devices before end of life," everyone in the field knows this is a budget and planning exercise. NCSC, 27 August 2026
"No patch, replace it"
Another face of the same lifecycle problem appears in a Rockwell advisory from September 2026. The 1756-ENBT is a communication module that connects ControlLogix PLCs to Ethernet. The advisory says a crafted CIP packet can crash the module, and the device needs a restart to recover. Affected versions: all of them. CISA, ICSA-26-246-05
The recommended fix is not a firmware patch; it is replacing the module with a 1756-EN2T or 1756-EN4TR. According to the manufacturer's product page, the 1756-ENBT was discontinued on 31 December 2021. Rockwell Automation, 1756-ENBT product page
What happens when the module crashes? The PLC itself keeps running and the logic executes. But the HMI cannot see that PLC, SCADA gets no data, and the operator is blind; we call this "loss of view." If the module also carries remote I/O or data shared with other PLCs, it is more serious: those connections drop and the outputs fall to the fault state defined in the project. The same crash only darkens a screen in one project and stops the process in another.
A site may have dozens of these modules, and none of them looks "insecure" on its own. It works, the light is green. Replacing it means stopping the line, ordering the new module and updating the module definition in the project file.
What do we do while there is no patch?
For the period in which we have to live with an old device, we have three tools: the network boundary, visibility and a plan.
| Situation | What to do | Why it works |
|---|---|---|
| The debug port may be open on EOL firmware | Close unnecessary ports, including 17185/udp, on the firewall in front of the RTU; allow the SCADA protocol and logged engineering access. If an old substation has no firewall, that comes first. | The 2010 advice still holds; if the port is unreachable, the vulnerability cannot be used. |
| Nobody knows which version is in the field | Record each RTU's model and firmware version in the inventory; verify the phrase "few legacy versions" against your own devices. | The advisory is version-based; without an inventory the risk cannot be assessed. |
| A communication module with no patch | Narrow the network that can reach the module and put it on the replacement plan; write down what the operator does if it crashes. | Loss-of-view time shrinks; the replacement enters the budget. |
| A major version jump is needed | In the outage window, test in a lab first, then pilot at one substation and verify. | No field change until protocol and relay compatibility are proven. |
These measures narrow access and reduce blind spots while the device vulnerability remains. The surrounding controls need strengthening until the upgrade or replacement plan is complete.
A component inventory is also needed. Another advisory published the same week describes an overflow bug in lwIP, an open-source network stack widely used in embedded devices. We cannot tell from the advisory itself which products are affected, because even the manufacturers often do not list which devices contain lwIP. CISA, ICSA-26-279-02 The VxWorks inside the RTU is the same kind of component. Asking for the list of software inside a device (an SBOM) at procurement time is the shortest way to answer "what was in it?" fifteen years later.
The question in the field
Looking at the label on the RTU during a substation walk-through is not enough. The question to ask is this:
Who last checked this device's firmware version, when, and who can reach this device over the network?