Oshili Power

An industrial gateway was handing out the keys to its own traffic.

The box that carries readings off an industrial site turns out to have kept its own secrets badly. Two weaknesses in the software of a widely deployed data gateway let someone already on the same local network read material the device holds in confidence, including the digital keys meant to keep its traffic private and to prove the device is the one it claims to be.

CISA, the American cyber security agency, published the advisory on 20 October, and the manufacturer has a corrected build available through the device's own management page. The agency lists the affected equipment across critical manufacturing, energy, and water and wastewater, and records it as deployed worldwide.

In practice this is the gear somebody fitted when plant data had to reach a corporate dashboard or a supplier's monitoring service and nobody was going to pull new cable: a mine's own water and power reticulation, the pumps and feeders it runs for itself, a bottling line, a pump station on a municipal supply. Nothing here stops any of it turning. The question for whoever recognises that arrangement is narrower, and it belongs with the person who owns the firmware on those boxes.

Where this lands on site

Both weaknesses need the attacker to be adjacent, meaning already on the same local network as the device rather than reaching it from the internet. That is reassuring until you remember which network it is. The segment a gateway sits on is the one that collects contractor laptops, a vendor's support tunnel and whatever got commissioned in a hurry during a shutdown.

The more serious of the two needs no account on the device at all. The key material is written into the software, so an attacker in the right place can work against both the confidentiality and the integrity of what the device sends and receives without ever logging in. A key compiled into a program is not a site secret. It travels with every copy of that program, which is what separates this from a badly configured box: the remedy is a build, not a setting.

The cost is scheduling. These units live in cabinets at the far end of things, and the upgrade runs through the device's own console, which means either a technician in front of it or a reliable route to it, plus a short window where the data it carries stops arriving. Where that gateway is the only path for readings from a remote substation or a pump house, the window is a control room watching nothing for a few minutes. That is a decision to take deliberately, not at the end of a shift.

The questions worth putting to whoever holds the maintenance record

The first is an inventory question rather than a security one: which gateways on site run this vendor's edge software, and at which build. The affected range reaches up to and including the release most sites will be running, so the answer is unlikely to be none.

The second is the one the advisory cannot answer for you. What were the keys inside those boxes trusted with? If the same material also authenticated the device to a cloud service, or vouched for the data it pushed, then the question extends past the device and into whatever accepted its word.

The third is contractual. The vendor's route to the fix runs through the device management console, by automatic check or by uploading the package by hand, which makes it a job for whoever holds credentials on the equipment rather than for whoever read the advisory. On a site where remote monitoring was sold as a service, that may not be your own team.

The technical record

Affected: Moxa AIG-302 ThingsPro Edge firmware 1.4.0 and earlier. Advisory ICSA-26-293-03, released 20 October 2026, headline CVSS v3 score 8.1. Sectors listed: critical manufacturing, energy, water and wastewater systems. Deployment: worldwide. Vendor headquarters: Taiwan.

CVE-2026-109812, missing authorisation (CWE-862) in the internal API /api/v1/secrets/: an authenticated attacker holding privileges, on an adjacent network, can reach sensitive information, including cryptographic key material. CVSS v3.1 6.8, medium, CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N. CVSS v4.0 6.9.

CVE-2026-109813, use of a hard-coded cryptographic key (CWE-321) in /usr/bin/sysman: an unauthenticated attacker on an adjacent network can use the exposed private key material to undermine the confidentiality and the integrity of the device's communications. CVSS v3.1 8.1, high, CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. CVSS v4.0 8.6.

Remediation: firmware v1.4.1. The upgrade is offered through the web console under Maintenance then Software Upgrades, either by checking for upgrades where the unit has internet access or by uploading a package downloaded from the product website or Moxa's software release service. Moxa's own notice, MPSA-262560, is the vendor record and the first place revisions will appear. CISA records neither flaw as reachable remotely and reports no exploitation aimed at them, and closes with its usual segmentation and remote-access guidance.

The advisory names the upgrade as the remedy and says nothing about retiring the key material that was exposed. Whether the new build closes this depends on what those keys were trusted to do, and that answer sits in the site's own records.

Source

  • cisa.gov /news-events/ics-advisories/icsa-26-293-03

Related briefs

Discuss this with us

Follow Oshili Power on LinkedIn