Jherrod ThomasThe Lion of Functional Safety™

May 24, 2026 · 13 min read

IEC 62443-4-1CRA / SBOMCWE-444

When the Bug Shipped Inside the Firmware

On May 14, 2026 CISA published an industrial-control-system advisory rating a Siemens power-monitoring device CVSS 9.1 — Critical for a flaw that lets an unauthenticated attacker take it over. Read the advisory closely and the interesting part is a single parenthetical: the vulnerability is "in the Go Project's net/http package." That is not a Siemens bug. It is a year-old, already-patched bug in a runtime that thousands of products link — and it took thirteen months to reach the people running the switchrooms.

I usually write about automotive and aerospace, but the cleanest functional-safety and cybersecurity convergence story of the last 30 days sits in the energy sector, and it has nothing to do with anyone writing bad code. It has to do with a missing artifact. Same shape as the rest of this blog: public record, standards lens, worked snippet, derived requirements, and what the headline actually tells us.

1. The public record

On May 14, 2026, CISA published ICS advisory ICSA-26-134-14, "Siemens SENTRON 7KT PAC1261 Data Manager" (CISA ICSA-26-134-14). Two days earlier, on the May 12, 2026 ICS Patch Tuesday, Siemens ProductCERT had released the matching vendor advisory SSA-783943 as one of 18 new Siemens advisories that cycle (SecurityWeek, ICS Patch Tuesday: New Security Advisories From Siemens, Schneider, CISA).

The device is mundane in the way that the most dangerous OT gear usually is. The SENTRON 7KT PAC1261 Data Manager is a DIN-rail-mounted, three-phase measuring device and data collector for low-voltage power distribution. It gathers electrical measured values across up to 96 outgoing load feeders, aggregates up to four SENTRON Powercenter 1000/1100 units, exposes a responsive web interface over LAN, and exports energy data as CSV (Siemens 7KT1261 system manual). It lives in building electrical rooms, data-center power distribution, and industrial switchrooms. Nobody calls it a safety device. Plenty of people leave its web UI reachable.

The advisory text is precise: the web server in 7KT PAC1261 firmware before V2.1.0 "contains a request smuggling vulnerability in the Go Project's net/http package that could allow an attacker to retrieve authorization tokens that can be used to gain administrative control over the device." CISA scores the device-level instance CVSS v3.1 9.1 (Critical) and classifies it as CWE-444 — Inconsistent Interpretation of HTTP Requests (HTTP Request/Response Smuggling). Every firmware version before V2.1.0 is affected; the fix is to update to V2.1.0 or later.

Now the part that earns this story a post. That "Go Project's net/http package" phrase points at CVE-2025-22871. That CVE was disclosed publicly on the oss-security mailing list on April 4, 2025, and fixed in Go 1.23.8 and Go 1.24.2 the same week (oss-security, CVE-2025-22871: Go net/http request smuggling; CVE-2025-22871 detail). The mechanism is small and nasty: Go's net/http server accepted a bare line feed — a \n with no preceding carriage return — as a valid terminator for a chunked-transfer chunk-size line. Put that Go server behind, or in front of, another HTTP component that treats a bare \n differently, and the two disagree about where one request ends and the next begins. That disagreement is request smuggling.

So the timeline reads:

For roughly thirteen months, every reachable 7KT PAC1261 ran a web server carrying a publicly documented, publicly fixed smuggling primitive — and the asset owners had no way to know, because the vulnerable component was invisible to them.

2. The standards lens

The instinct is to file this as a Siemens defect. It mostly is not. Nobody on the 7KT team wrote a broken chunk parser; they linked a Go runtime and the runtime had the bug. That makes this the exact failure mode IEC 62443-4-1 — Secure product development lifecycle requirements exists to catch. Three practices apply, and the device tripped all three.

SM-9 — Security requirements for externally provided components. IEC 62443-4-1 Practice 1 obliges the product supplier to identify every externally provided component — commercial, open-source, or language runtime — and to track its security posture across the product's life. In 2026 the operational form of SM-9 is a software bill of materials. If the 7KT firmware SBOM carried a line item reading "Go standard library net/http, built on Go 1.x.y," then CVE-2025-22871 becomes a database lookup that anyone could run, not a discovery that waited for a Patch Tuesday. The advisory is, in effect, a public confession that no such monitored SBOM existed — or that it existed and nobody queried it.

DM-1 and DM-3 — Receiving and assessing security-related issues. Practice 6, defect management, requires the supplier to receive notifications about issues in third-party components and to assess whether shipped products are affected. The Go security team publishes machine-readable advisories — the Go vulnerability database, consumable by govulncheck. A conforming DM process subscribed to that feed flags CVE-2025-22871 within days of April 4, 2025. Thirteen months of latency is not a slow DM process; it is the absence of one for this dependency class.

SUM-3 and SUM-5 — Dependent-component update documentation and timely delivery. Practice 7, security update management, says that once an issue is assessed, the qualified update has to reach the asset owner on a defined timeline. SUM-5 is explicit about timely delivery of security patches. Thirteen months is not a timeline; it is what happens when there is no clock running.

There is also a component-level standard to name. IEC 62443-4-2 defines the technical security capabilities a component must demonstrate. The realized impact here — an unauthenticated party lifting a valid authorization token — is a failure against Foundational Requirement FR 1, Identification and Authentication Control: the token's confidentiality and the session's integrity were not preserved. The smuggling bug is the vector; the stolen token is the FR 1 breach.

One convergence point worth stating plainly. This is no longer just good practice. The EU Cyber Resilience Act entered into force in December 2024, and its vulnerability-handling and reporting obligations phase in through 2026 and 2027. For an energy-sector product with digital elements sold into the EU market, a maintained SBOM and a monitored third-party-component vulnerability process move from "mature engineering" to a CE-marking precondition. ICSA-26-134-14 is a preview of what CRA non-conformance is going to look like in an audit.

3. A worked snippet — threat scenario, attack tree, and the SBOM line that should have existed

Because this is a cyber story, the right worked artifact is an IEC 62443-3-2-style threat-risk row, an attack tree, and — most important — the SBOM excerpt whose absence is the actual root cause.

Threat-risk row

| Field | Value | |---|---| | Scenario ID | TS-7KT-01 | | Asset | SENTRON 7KT PAC1261 web server — session and authorization-token authority | | Threat | Unauthenticated HTTP request smuggling to harvest a valid administrative authorization token | | Vector | CVE-2025-22871 — bare-LF chunk-size desynchronization between the Go net/http server and an upstream proxy or load balancer | | FR violated | FR 1 (Identification and Authentication Control); secondary FR 3 (System Integrity) | | Exploitability | High — public CVE, well-documented technique, no credentials required, network-reachable | | Impact | Full administrative control of the data manager; falsified or suppressed energy data; pivot foothold on the power-monitoring VLAN | | Unmitigated risk | High | | Treatment | Update firmware to V2.1.0; enforce IEC 62443-3-2 zone/conduit segmentation; remove all internet-reachable paths to the web UI | | Residual risk | Low |

Attack tree (top event: attacker gains admin control)

Top: Attacker gains administrative control of SENTRON 7KT PAC1261
        AND
        |-- 1. Network path to the device web server is reachable
        |       OR
        |       |-- 1a. Device web UI exposed to the internet (Shodan-discoverable)
        |       +-- 1b. Attacker already resident on the building / OT LAN
        +-- 2. Valid authorization token obtained without credentials
                OR
                |-- 2a. Request smuggling via bare-LF chunk desync   [CVE-2025-22871]
                |       AND
                |       |-- 2a-i.  Go net/http server accepts a bare LF in the chunk-size line
                |       +-- 2a-ii. Upstream HTTP component interprets the bare LF differently
                +-- 2b. (separate path) credential reuse or default credentials

Note the structure: leaf 2a-i is the inherited Go defect. Leaf 2a-ii is a deployment condition the asset owner controls. The vendor fix removes 2a-i; segmentation and a clean reverse-proxy posture suppress 2a-ii and node 1. Defense in depth means you do not need both leaves to fail-safe — but you do need to know leaf 2a-i exists, and that is exactly what the SBOM provides.

SBOM excerpt — the line item that was missing

| Component | Type | Version (pre-fix firmware) | Known CVE | Upstream disclosure | Status before V2.1.0 | |---|---|---|---|---|---| | Go standard library net/http | Language runtime / OSS | built on Go before 1.23.8 / 1.24.2 | CVE-2025-22871 | 2025-04-04 | Vulnerable — unpatched roughly 13 months | | 7KT application / web layer | First-party Siemens code | — | — | — | Not the defect — inherited the defect |

If that first row had existed in a machine-readable SBOM wired to the Go vulnerability feed, the "Status" cell would have flipped to red in April 2025, and this advisory would have shipped about a year sooner.

4. Derived cybersecurity requirements (excerpt)

Five traceable requirements, each tied to the clause that should have generated it. These are the artifacts a 7KT-class product file should already carry.

Every one of these traces upward to a named IEC 62443-4-1 or 4-2 clause and downward to a verifiable test. CSR-7KT-004 in particular is the requirement that, had it existed and been verified, would have made the device immune to CVE-2025-22871 regardless of which Go runtime it linked — because a server that demands a full CRLF cannot be desynchronized by a bare LF.

5. What the headline really tells us

"Siemens power monitor vulnerable to device takeover" reads like a Siemens coding failure. It is not, quite. The defect was a year-old, already-patched flaw in a language runtime that an enormous number of products depend on. What Siemens — and, to be fair, most OT vendors — were missing is not better code. It is the artifact that makes inherited risk visible: an SBOM, wired into a defect-management feed, wired into an update clock.

Without that chain, a product's security posture is effectively frozen on its ship date while the world's CVE database keeps moving underneath it. The vulnerability did not appear in May 2026. It appeared in April 2025, and the device simply could not see it. ICSA-26-134-14 is not the failure. The advisory is the SBOM — assembled by CISA, on the public's behalf, thirteen months late. The engineering job is to make sure your own product file produces that artifact first.

If you build or operate OT gear and you cannot answer "which third-party CVEs are open against firmware currently in the field" from a live SBOM in under a minute, that gap — not the next advisory — is the actionable item. The contact link on the main site is the fastest way to reach me if you want to walk through wiring SM-9, DM, and SUM into a real release pipeline.

— Jherrod Thomas, The Lion of Functional Safety™

Sources