On 6 October 2026, CISA republished two Hitachi Energy advisories for the energy sector: ICSA-26-279-06 for RTU500 series CMU firmware and ICSA-26-279-05 for REB500. Hitachi's own PSIRT first released both on 29 September 2026. This is not an incident. Neither advisory reports exploitation in the wild, and both carry an SSVC string with exploitation set to none.
It still deserves attention because the RTU500 findings include a pair of unauthenticated critical flaws in a product that reaches substations and remote sites.
What is affected
RTU500 series CMU firmware. Versions 11.x and prior, which the advisory describes as end of life. Hitachi says currently supported firmware is not affected. Fixed versions are 12.7.8, 13.9.1 or later. Dragos reported the issues to CISA.
REB500. Versions 8.3.3.1 and prior. The fix is 8.3.4.0. Hitachi Energy's internal team reported these.
The vulnerabilities
For RTU500, the highest CVSS v3.1 score in the advisory is 9.8, from an old VxWorks debug service entry.
| CVE | Weakness | CVSS v3.1 | Summary from the advisory |
|---|---|---|---|
| CVE-2026-8065 | CWE-306 missing authentication | 9.1 | Unauthenticated firmware upload through the update endpoint |
| CVE-2026-8066 | CWE-23 path traversal | 9.1 | Unauthenticated write or overwrite of arbitrary files through file upload |
| CVE-2026-8067 | CWE-862 missing authorization | 6.5 | Authenticated user can trigger a reboot |
| CVE-2010-2965 | CWE-863 | 9.8 | VxWorks WDB debug service on UDP 17185, only a few legacy versions use it per Hitachi |
| CVE-2014-9195 | CWE-306 | 8.1 | Unauthenticated remote command execution through a network service |
| CVE-2023-46143 | CWE-494 | 7.5 | Unauthenticated remote modification of applications on the device |
For REB500, two libexpat issues in the IEC 61850 functionality: CVE-2024-8176 (uncontrolled recursion, stack overflow) and CVE-2025-59375 (unbounded memory allocation). Both score 6.5. The impact is denial of service and, depending on environment, memory corruption. The advisory text says the attacker is an authenticated user with local access, while the CVSS vector says network. The advisory does not explain the difference, so treat both as possible.
Confirmed, reported and unknown
Confirmed by the vendor and CISA: the affected and fixed versions, the CVE list and scores.
Reported as not happening: exploitation. The advisories do not describe any.
Unknown: how many 11.x units remain deployed, and how many are reachable from outside their site network. Neither advisory gives a count.
Why it matters
Hitachi's explanation is plain: legacy firmware was built to the security requirements of its time, and later releases added stronger authentication, access controls and encrypted communications. End of life firmware gets no patches, so the fix is a firmware upgrade, not a hotfix.
In operational technology, upgrades are planned around outages and testing, so old versions linger. That is why the mitigation advice carries as much weight as the patch.
What to do now
- Inventory every RTU500 CMU and record its firmware version. Anything on 11.x or earlier goes on an upgrade plan to 12.7.8, 13.9.1 or later.
- For REB500, plan the move to 8.3.4.0.
- Confirm none of these devices is reachable from the internet, as the advisories direct.
- Keep control networks behind firewalls and separated from business networks.
- Where remote access is needed, use a VPN and keep it updated. The advisory notes a VPN is only as secure as the devices connected to it.
- Do an impact and risk assessment before changes, as CISA and Hitachi recommend.
- Block or monitor UDP 17185 on segments that carry legacy units, since that is the port of the debug service in CVE-2010-2965.
How this could have been avoided
- A supported firmware policy. The critical findings sit only in end of life versions. Tracking firmware age against vendor support dates flags them early.
- Network segmentation. Unauthenticated flaws in management endpoints matter far less when only a jump host can reach them.
- Disabling unneeded services. The VxWorks debug service is only dangerous if it is reachable.
- Component inventory. The REB500 issues come from a bundled library, libexpat. Knowing which products embed which library tells you where a library CVE lands.
Try it yourself
List your OT assets by vendor, model, firmware version and vendor support end date, then sort by the date. The demo shows how a vulnerability queue looks when you rank by exposure.
Click through it at your own pace, or open it full screen.
Quick check
Which RTU500 firmware versions are affected, and what fixes them?
Versions 11.x and prior, which are end of life. Upgrade to 12.7.8, 13.9.1 or later.
Do the advisories report active exploitation?
No. Both carry an SSVC string with exploitation set to none.
