The list of software flaws under active attack now reaches the engineering desk.

The American cyber defence agency keeps a public register of software flaws it has evidence of attackers actually using, as distinct from flaws that merely could be used. On 20 October it added six. Five of them are products of the office and the home. The sixth is a Siemens tool for managing that vendor's own software, and it is the one that belongs in an industrial conversation.

The register exists to settle an argument about order. Any sizeable operation carries more outstanding patches than it can schedule, and a list of this kind is a way of saying which ones have stopped being hypothetical. That makes it a document for whoever owns the patch schedule. In most industrial organisations, that person's remit stops at the edge of the plant network and does not clearly extend to the machines used to program what sits inside it.

What the register will not do is tell an operator whether they are exposed. Each entry carries an identifier and a weakness type, and nothing further: no affected versions, no scores, no remediation note.

What this touches on site

The weakness named in the Siemens entry is an uncontrolled search path element, meaning a program that needs a file from somewhere on the machine can be made to find the wrong one first. The practical reading of that class is narrow and worth being precise about. It is not a remote strike on a substation. It is a route for somebody who already has a presence on a machine to run their own code with the standing of a trusted program.

So the question becomes which machine. A vendor's software management tooling lives wherever that vendor's engineering software gets installed and updated: configuration laptops, engineering workstations, the contractor's machine that arrives in a flight case for a commissioning job. Those are the machines holding the project files, the firmware images and the configuration backups for whatever they are pointed at.

On a mine running its own reticulation, or a distribution utility, the consequence is not a trip. Nothing stops. It is slower and more expensive than that: a machine nobody can fully vouch for, project files and backups in the same position, and a maintenance window spent re-verifying what should already have been settled rather than doing the planned work. The call goes to the integrator, and then to whoever can say when the engineering estate was last patched. That is a different record from the plant one, and in many places a thinner one.

The exploitation evidence is what changes the arithmetic here. Entries go on this list because the agency has reason to believe they are being used, not because they scored highly.

The questions this leaves

The first is a question of inventory, and it is unglamorous. Is the vendor's own software management tooling on the asset register at all, or does the register cover the equipment and skip the tools that configure it? An operator who cannot answer that from a document has found the real finding, and it is not a Siemens one.

The second points outward. Integrators and OEM service teams arrive with their own machines and their own software estates. The question worth putting to whoever holds the maintenance contract is which of those machines carry the vendor tooling, and whose change control they sit under.

The third is borrowed. Alongside the catalogue, the agency operates a binding directive that ranks remediation by risk: publicly reachable systems come first where a successful attack would hand over the whole machine, and lower-risk items are deliberately left for later. It also expects an agency to establish whether a system had already been broken into before the fix went on. That second half is the question most maintenance records cannot answer, and it is the one worth asking about any patch applied quietly some months ago. The directive binds only American federal civilian agencies, and the agency's position is that everyone else should work to the same risk ordering.

A register of active exploitation answers one question and only one: which items on the backlog have stopped being theoretical. It cannot say whether the software is anywhere on the estate. That answer lives in an inventory, and the entry that matters here belongs to the half of the estate most industrial inventories were never built to cover. Establishing whether that inventory exists is the larger piece of work, not the patch.

The technical record

Six entries, added 20 October 2026, each on the basis of exploitation evidence rather than score alone. The alert groups them by product and weakness type:

• CVE-2026-110936, Siemens Software Center, where the weakness is given as an uncontrolled search path element.
• CVE-2026-96652 and CVE-2026-96655, Plex Media Server, two server-side request forgery entries.
• CVE-2026-96654, Plex Media Server, improper neutralisation of encoded URI schemes, a web page handling weakness.
• CVE-2026-96656, Plex Media Server, external control of a file name or path.
• CVE-2026-106931, SiteGuard Server Edition from EG Secure Solutions, listed for operating system command injection.

No affected version ranges, severity scores, attack vectors or remediation detail accompany any of the six, and the alert does not link the vendor advisories behind them. Nominations to the catalogue are required to carry a CVE identifier, evidence of exploitation and clear mitigation guidance, so remediation detail exists somewhere for each; this alert is not where it is set out. Patch status is recorded here as not stated rather than as unpatched, and an operator wanting the affected builds for the Siemens item will find them at the vendor, not in the catalogue entry.