CVE-2026-106087: TRO600 File Read Hands Attackers the Router's Secrets

Hitachi Energy's TRO600 series routers carry an unauthenticated arbitrary file read flaw tracked as CVE-2026-106087. An attacker who can reach the affected service does not need an account, a session or user interaction: according to the vendor advisory, they can read or download arbitrary files on the device, including sensitive configuration files and password data. CISA republished the vendor notice on 29 October 2026 as ICSA-26-302-02, and the fix is firmware 9.2.2.1, with 9.1.2.0 named as the fixed build for the older branch.

That combination is what makes this advisory more than a routine patch note. A file read on a cellular or mesh router is not a file read on a laptop. The router is the device that holds the credentials for the links around it: the VPN that joins a substation to the control centre, the SNMP and AAA secrets that let the network management platform talk to it, the Wi-Fi and mesh keys that hold the field network together. Reading those files is a way to stop guessing and start logging in. The vulnerability is scored 7.5 on CVSS v3.1 and 8.7 on CVSS v4.0; the newer score is higher because v4.0 weighs the confidentiality loss more heavily against a device that is, by design, reachable over a network.

Key takeaways

• The flaw needs no credentials. CVSS v3.1 vector is AV:N/AC:L/PR:N/UI:N, meaning network reachability, low complexity, no privileges and no user interaction.
• The impact is disclosure, not execution. The advisory describes reading or downloading arbitrary files, including configuration files and password data. Integrity and availability are scored as no impact.
• Both firmware branches are affected. TRO600 at 9.2.1.6 and prior, and at 9.1.1.0 and prior, are listed. Fixed builds are 9.1.2.0 and 9.2.2.1.
• 9.1.2.0 does not close the whole advisory. The second flaw in the same notice, CVE-2026-10756, lists 9.2.2.1 as its remediation. If you are upgrading anyway, go to 9.2.2.1.
• No known exploitation as of 29 October 2026. The CVE is not in CISA's Known Exploited Vulnerabilities catalog (catalog version 2026.10.29, 1,764 entries), and the vendor SSVC record carries E:N for exploitation status.
• Treat any unpatched, reachable unit as a credential exposure. Patching closes the door; it does not undo a read that already happened. Rotate the secrets the device stored.

Our earlier summary of the 29 October CISA release covered all three advisories. This piece stays with CVE-2026-106087, because the operational question is narrower and more awkward than the headline: which files, which secrets, and how do you prove a unit is fixed when the advisory lists the fixed build inside the affected-version string?

What the advisory actually says

The wording is short enough to quote in full. TRO600 contains an arbitrary file read vulnerability. An unauthenticated attacker can exploit it to read or download arbitrary files on the affected device, including sensitive configuration files and password data, resulting in the disclosure of sensitive information. The weakness class is CWE-306, missing authentication for a critical function. In other words, the file-access function exists by design; what is missing is the check that should have stood in front of it.

The scores matter because they describe how the flaw behaves, not how bad the outcome feels. The v3.1 vector reads CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Network reachable, low complexity, no privileges, no user interaction, high confidentiality impact, no integrity or availability impact. The v4.0 vector reads CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N and lands at 8.7. There is no exploit maturity component in either public score, which is the polite way of saying the score does not tell you whether someone has already written a tool.

Note the shape of the affected-version line. It names two ranges and then appends the fixed builds in the same field. That is a data-modelling artefact of how the advisory was generated, not a statement that the fixed builds are vulnerable, but it has a practical consequence: you cannot close a ticket on the strength of a purchase order, a label or a remembered version. You have to read the build string off the device.

Why a file read is a credential breach

Industrial routers are not general-purpose computers, and that is exactly why their file system is worth stealing. A field router in a distribution automation network typically holds a configuration file that describes its entire role: interface addresses, VLANs, routing rules, firewall policy, the addresses of the network management platform and the syslog collector, and the credentials it uses to authenticate to each of them. Around that file sit the keys that make the links work.

Three categories deserve attention. First, pre-shared secrets. IPsec and VPN pre-shared keys, Wi-Fi and mesh passphrases, and SNMP community strings cannot be stored as one-way hashes, because the device has to send the secret itself. If they are in the configuration file, reading the file yields working credentials. Second, authentication material. Local user records and AAA secrets may be hashed, but a hash is an offline problem, not a barrier, and embedded devices have historically been slow to adopt memory-hard password hashing. Third, trust anchors. Certificates and private keys, enrollment tokens for the management platform, and API keys for northbound integrations are all files, and all of them are useful to someone who wants to impersonate the device or the operator.

What follows is not speculative chain-building; it is the ordinary consequence of where the device sits. A TRO600 is a Layer-3 edge device. It routes between a cellular or mesh WAN and the substation or field LAN where RTUs, protection relays, meters and gateways live. The management platform that provisions it, SuprOS, sits north of it and manages TRO600 routers alongside RTU500 controllers. Credentials read from one router can therefore be tried against the management plane, against peer routers that share a mesh key, and against any service that reuses the same accounts. The advisory does not claim that any of this has happened. It does not have to. The file read supplies the material that makes the next step possible.

There is a second-order problem that asset owners tend to discover late: the same credentials are often shared across a fleet. Utilities standardise because standardisation is how a small team manages thousands of field devices. That efficiency becomes blast radius when one device leaks. If the SNMP community string on a substation router is the same string used by the network management system across a region, the file read is not a single-device event.

Which builds are in scope, and which fix closes what

The advisory covers two firmware branches. The 9.2 branch is affected at 9.2.1.6 and prior and is fixed at 9.2.2.1. The 9.1 branch is affected at 9.1.1.0 and prior and is fixed at 9.1.2.0. Both CVEs in the advisory are listed against TRO600, but they do not have the same remediation line, and that difference is the single most useful thing to carry into a maintenance window.

CVE-2026-10756 is the quieter half of the pair. It requires authentication, which is why its v3.1 score is also 7.5 but its vector is different: high attack complexity and low privileges. An authenticated attacker can bypass network access restrictions and reach services that were intended to be reachable only from localhost, using port forwarding to interact with locally bound ports. This is the classic difference between a bug that lets you in and a bug that lets you move once you are in. It is fixed in 9.2.2.1, and the advisory does not list a 9.1 fix for it.

The practical reading is simple. If you are on 9.1.x and your only goal is CVE-2026-106087, 9.1.2.0 is a defensible target. If you are planning the window anyway, 9.2.2.1 closes both CVEs and avoids a second trip to every site. That decision belongs to the asset owner, because a branch upgrade carries more regression risk than a point fix and some utilities deliberately stay on a long-lived branch. The one thing that is not defensible is closing the ticket at 9.1.2.0 while recording the advisory as fully remediated.

Is anyone exploiting it yet?

As of 29 October 2026, there is no public evidence of exploitation. The CVE does not appear in CISA's Known Exploited Vulnerabilities catalog, whose 2026.10.29 revision lists 1,764 entries, and the advisory's SSVC record carries E:N, which is the exploitation status of none. The vendor and CISA both describe the issue without an in-the-wild qualifier.

Those facts are worth stating precisely because they are easy to misread. Not being in KEV means CISA has not confirmed exploitation, not that exploitation is impossible. The economics of this flaw are unusually favourable to an attacker who already has a foothold: no credentials, no user interaction, low complexity, and a payload that is plain data rather than code execution. A file read is also quiet. There is no crash, no service restart, and no obvious signature beyond an HTTP request that looks like any other request to the device. An operator who only looks for failed logins will see nothing, because the successful request never logs in.

Where this CVE is likely to matter first is not a headline intrusion but a post-incident review. A utility that finds an unexplained configuration change, a new VPN peer or an unusual management connection may need to ask whether a TRO600 was read before the change happened. That question is answerable only if the firmware inventory is accurate and the management-plane logs were retained.

How to tell whether a unit is actually fixed

Version checking on embedded devices is where good intentions go to die. The advisory lists 9.2.2.1 and 9.1.2.0 as the fixes, and the same strings appear inside the affected-version field. Labels on the chassis describe the hardware, not the running image. A device that was staged two years ago and never updated will report whatever it shipped with. The only trustworthy source is the running build, read from the device itself.

Two details are easy to miss. The first is the lab and training pool. Utilities keep spare and training routers that are powered on intermittently and patched last, if at all. The second is the vendor remote-access path. Many sites have a support tunnel that terminates inside the OT zone for maintenance; if that tunnel can reach the router management interface, the device is network-reachable in the sense the CVSS vector means, even if it has no public address.

What to do this week if you run TRO600

1. Stop treating the management interface as an internal service. Put it behind a jump host, restrict it to the management VLAN, and remove any rule that lets the cellular WAN reach it. CISA's standing advice is the same: minimise network exposure, keep control systems off the internet, and use a VPN for remote access while remembering that the VPN is only as strong as the devices at both ends.
2. Patch to 9.2.2.1 where the branch allows it. Where a branch freeze forces 9.1.x, go to 9.1.2.0 and record explicitly that CVE-2026-10756 remains open on that unit.
3. Rotate the secrets the device stored. Change SNMP communities, AAA shared secrets, VPN and IPsec pre-shared keys, mesh and Wi-Fi passphrases, and local administrative passwords. If the same secrets are used elsewhere in the fleet, change them there too. This is the step most often skipped, and it is the one that addresses the actual impact.
4. Look for reads, not logins. Pull HTTP and management-plane logs for the exposure window and look for requests to unusual paths, large responses, and sequences that do not match normal polling. Absence of failed authentications proves nothing on a flaw that requires no authentication.
5. Check the downstream trust. Review SuprOS and NMS accounts that the router used, certificates issued to it, and any API tokens stored on the device. If those credentials could be read, treat them as disclosed until rotated.
6. Watch the KEV list and the vendor advisory. A KEV addition or a public proof of concept changes the urgency, not the remediation.

For teams that are re-segmenting a substation network at the same time, the adjacent work is familiar. A managed switch with proper VLAN support replaces the unmanaged switch that put the router, the RTU and the engineering laptop on one flat segment; a firewall module or a control firewall sits between the field network and the management plane; fibre media converters extend the segment without extending the copper. The hardware below is the kind of spares utilities ask for when they do that work, and none of it is a substitute for patching the router.

The spares question: what to hold while the fleet is patched

A firmware campaign on field routers has a predictable side effect: units come back from site with older builds, or fail during the upgrade and need replacement. The devices that surround the router are usually older than the router itself, and their spares position is worse. Three groups matter.

RTU and I/O spares. The router exists to carry traffic from RTUs and protection equipment. If an RTU is taken out of service during the network work, the parts that fail are the ones that were already marginal: power supplies, analog input modules and serial communication cards. Examples in the ABB RTU560 family include the 560PSU02 power supply and the 560AIR02 analog input module, both stocked as refurbished spares. On the Schneider side, the 140NWM05000C RTU module and the BMXNOR0200 serial module are the parts that keep a Modicon installation talking while its upstream link is rebuilt.

Segmentation hardware. The most common compensating control for a router flaw is to stop the router from being reachable by everything. That means managed switching and a firewall in front of the management plane. Useful spares include the Siemens SCALANCE S602 firewall module, the 6GK5206 6-port managed IE switch and 6GK5208 8-port managed switch, the Stratix 5700 1783-BMS20CGN and the Stratix 2000 1783-US8T, the Lenze RS20 16-port managed switch, and the Schneider TCSESM083F2CU0. For sites that separate the process network from the business network, the Honeywell CC-PCF901 control firewall module is the equivalent part in the Honeywell FTE world.

Physical-layer and protocol conversion. Substation upgrades rarely stop at the router. Fibre uplinks need media converters and cable, and legacy serial devices need a path to Ethernet. The ABB TB825 multi-mode optical media converter and TB826 single-mode converter cover the S800 I/O side, the 6XV1820 fibre cable covers the patch, and the GE IC200SET001 Ethernet-to-serial module and 1734-485ASC serial interface handle the legacy tail. Where the link is Ethernet/IP to PROFINET, the ProSoft PLX32-EIP-PND gateway is the usual adapter.

None of these parts fixes CVE-2026-106087, and none of them is a TRO600. The point is narrower: the patch window is when the surrounding network gets touched, and the spares that fail are usually not the device that prompted the work. Buyers can browse the communication modules, network adapters, Ethernet switch and protection relay categories, or the ABB, Siemens, Allen-Bradley and Schneider Electric archives, to check what is available as refurbished stock.

What to watch next

Three signals would change the picture. A KEV addition would mean confirmed exploitation and would pull the patch forward for US federal and critical-infrastructure operators. A public proof of concept would shorten the window between disclosure and opportunistic use, because the flaw needs no credentials or complex setup. A revision of the vendor advisory could clarify the affected-version ranges or add a fix for the 9.1 branch of CVE-2026-10756.

None of those has happened as of 29 October 2026. What has happened is that a class of device which sits at the boundary between the field and the control centre has been shown to hand over its configuration to anyone who can reach it. Utilities that treat that boundary as a trust boundary rather than a convenience will be fine. Utilities that still run a flat management VLAN will be doing this again next year, with a different CVE number.

For the wider policy picture, the same logic runs through our review of CISA's 2030 strategy and what it means for legacy PLCs and spare-parts planning. The weak point is rarely the newest controller; it is the connectivity layer that grew up around it, often without an owner. The PHP2Shell flaw and industrial web interfaces made a similar point from the application side: web-facing management surfaces on OT equipment are the part of the estate that ages fastest and gets patched slowest.

Frequently asked questions

What is CVE-2026-106087?

It is an arbitrary file read vulnerability in Hitachi Energy TRO600 series routers, disclosed by Hitachi Energy and republished by CISA as ICSA-26-302-02 on 29 October 2026. It is classified as CWE-306, missing authentication for a critical function, and scored 7.5 on CVSS v3.1 and 8.7 on CVSS v4.0.

Does an attacker need credentials?

No. The CVSS v3.1 vector is PR:N, meaning no privileges are required, and UI:N, meaning no user interaction. An attacker who can reach the affected function can read or download files without logging in.

Which TRO600 versions are affected?

The advisory lists TRO600 version 9.2.1.6 and prior, and version 9.1.1.0 and prior. Both branches are affected by CVE-2026-106087. Read the running build from the device rather than relying on labels or purchase records.

Which firmware fixes it?

Hitachi Energy names 9.1.2.0 as the fixed build for the 9.1 branch and 9.2.2.1 as the latest fixed release. 9.1.2.0 closes CVE-2026-106087 only. CVE-2026-10756, the localhost port-forwarding flaw in the same advisory, is remediated by 9.2.2.1.

Is the vulnerability being exploited in the wild?

There is no public evidence of exploitation as of 29 October 2026. The CVE is not in CISA's Known Exploited Vulnerabilities catalog, and the vendor SSVC record carries an exploitation status of none. That can change without notice, so treat the absence as a scheduling input, not a guarantee.

What data can an attacker read?

The advisory states that an unauthenticated attacker can read or download arbitrary files, including sensitive configuration files and password data. In practice that means any secret the device stores, which on a field router typically includes management credentials, SNMP and AAA secrets, VPN and mesh keys, and certificates.

What should we do if we cannot patch immediately?

Remove reachability first: put the management interface behind a jump host, restrict it to the management VLAN, and block the cellular WAN and vendor tunnels from reaching it. Then rotate the secrets the device holds, because reachability controls reduce the chance of a read but do not undo one that already happened. Patch to 9.2.2.1 as soon as the maintenance window allows.

Sources

CISA ICS Advisory ICSA-26-302-02, Hitachi Energy TRO600 series products, republished 29 October 2026, a verbatim republication of Hitachi Energy PSIRT advisory 8DBD000224. NVD entry CVE-2026-106087, published 27 October 2026, CWE-306, CVSS v4.0 8.7. CISA Known Exploited Vulnerabilities catalog, version 2026.10.29, 1,764 entries. CISA ICS Advisory ICSA-24-317-02, Hitachi Energy TRO600, 12 November 2024, covering CVE-2024-41153 and CVE-2024-41156 and the 9.2.0.5 remediation. Hitachi Energy product material for the TRO600 series and SuprOS network management.

Disclosure: AutoDCS is an independent supplier of refurbished industrial automation and control spares. We do not manufacture, distribute or support Hitachi Energy TRO600 firmware, and nothing in this article is a substitute for the vendor advisory or for a maintenance procedure approved by the asset owner.