Jherrod ThomasThe Lion of Functional Safety™

June 26, 2026 · 14 min read

IEC 62443-4-2 / 4-1IEC 61850 / NERC CIPCVE-2025-40808 / CWE-434

When the Relay Could Be Reflashed Over Its Own Engineering Port

A protection relay has exactly one job that matters: watch the current and voltage on a line, and when a fault appears, trip the breaker in a handful of milliseconds before the arc destroys the transformer, the bus, or the person standing near it. It is the safety function for the primary equipment. So when an advisory says that anyone with a valid login can upload an arbitrary file to that relay over its engineering protocol — and thereby brick it or rewrite what it considers a fault — the interesting question is not the CVSS score. It is why the integrity of a grid-protection device was ever allowed to rest on one application-layer password.

On June 23, 2026, CISA re-released advisory ICSA-26-174-02, "Siemens SIPROTEC 5 Using DIGSI 5 Protocol," elevating attention on CVE-2025-40808. The flaw is mundane in isolation and ugly in context: an authenticated user can upload arbitrary files to a broad swath of the SIPROTEC 5 protection-relay family through the DIGSI 5 engineering protocol, with no adequate check on file type, name, or destination. The documented consequence is a permanent denial-of-service condition, with code execution on the table. The engineering story is not the upload handler. It is that the device whose entire reason to exist is trustworthy fault clearing has no integrity backstop under the path an engineer uses to configure it.

1. The public record

ICSA-26-174-02 — CVE-2025-40808, Siemens SIPROTEC 5 via DIGSI 5. Per CISA and Siemens ProductCERT, the file-upload mechanism of the DIGSI 5 protocol fails to validate uploaded content. An authenticated user — someone who has logged in to a SIPROTEC 5 device — can send a crafted upload request that bypasses the normal checks on file type, name, and destination and writes an arbitrary file to the device. The weakness is classified CWE-434 (Unrestricted Upload of File with Dangerous Type), sitting on top of an improper-input-validation root cause. The stated impact is a permanent denial of service; because an uploaded file can land where it may be executed or integrated into the device runtime, remote code execution is the credible worst case.

The base score is the part worth pausing on. The published CVSS v3.1 base is 6.1 (Medium), vector CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H — adjacent network, low attack complexity, high privileges required, no user interaction, no confidentiality impact, but high integrity and high availability impact. The two things dragging that number down to "Medium" are adjacent network (AV:A) and high privileges required (PR:H). In an enterprise IT context those are real mitigations. In a substation, they are close to free: DIGSI 5 access lives on the station network by design, engineering credentials are routinely shared across maintenance crews, jump hosts, and contractor laptops, and a stolen VPN credential or a compromised engineering workstation hands an attacker exactly the "adjacent, authenticated" position the vector assumes is hard to reach. A 6.1 that can permanently disable a transmission-line protection relay is not a 6.1 in the operational sense, and treating the score as the risk is the first mistake.

The fix. Siemens has published firmware that introduces an upload allow-list, restricting which files the device will accept. For CP050 and CP150 device variants the fixed version is v9.90 or later; for CP300 variants the 7ST85 and 7ST86 devices move to v10.00 or later, with the remaining CP300 models on v9.90 or later. The advisory covers dozens of products across the SIPROTEC 5 line, which spans overcurrent and feeder protection (7SJ8), distance protection (7SA8), line differential (7SD8), transformer protection (7UT8), breaker management (7VK8), and the associated bay controllers. CISA's layered guidance is the usual OT trio applied to engineering access: patch, segment the network so DIGSI 5 traffic cannot be reached from IT or the internet, and enforce strong, unique authentication.

Two things keep this above patch-Tuesday noise. First, this is not SIPROTEC 5's first rodeo: the same platform drew CISA advisories earlier in this cycle (for example ICSA-26-134-13 in May 2026 and ICSA-25-016-04 in January 2025). A device family that keeps surfacing issues at its engineering and communication interfaces is sending a design signal, not throwing accidents. Second — and this is the part the security write-ups underplay — the affected device is the protection layer of the bulk electric system. The thing an attacker can brick or quietly re-parameterize is the thing standing between a line fault and a substation fire.

2. The standards lens

Three standards families meet on this relay, and the failure is best understood as a gap that each of them already names.

On the product-security side — IEC 62443-4-1 and -4-2. CVE-2025-40808 is a textbook escape from the secure development lifecycle of IEC 62443-4-1: the practice area for secure implementation and security verification requires that externally reachable interfaces validate their inputs and that the product be tested against malformed and abusive input. An upload handler that accepts arbitrary file type, name, and destination is the artifact of that practice not being run against the DIGSI 5 file path. At the component level, IEC 62443-4-2 is even more specific. CR 3.5 (Input validation) requires the component to validate the syntax and content of inputs that affect its operation — the missing control here. CR 3.4 (Software and information integrity) requires the component to verify the integrity of software and configuration — which, done properly, means cryptographically signed firmware and config that the relay refuses to load if the signature does not chain to a hardware root of trust. The allow-list Siemens shipped narrows the input-validation gap (CR 3.5); it does not, by itself, give you the integrity guarantee (CR 3.4). An allow-listed-but-unsigned upload path still trusts whatever the authenticated session hands it.

On the system side — IEC 62443-3-2 and -3-3, and IEC 61850. The relay does not live alone; it lives in a substation automation system governed in practice by IEC 61850 (station bus, process bus, GOOSE and MMS messaging) and engineered with DIGSI 5. The system-level obligation is to put engineering access inside its own zone with a controlled conduit (IEC 62443-3-2 zones and conduits), and to enforce authentication and integrity at the system level (IEC 62443-3-3 SR 1.1/1.2 for identification and authentication, SR 3.4 for software and information integrity, and the SR 7.x availability family for the DoS outcome). The reason this matters more than for a generic PLC: a SIPROTEC 5 relay participates in IEC 61850 GOOSE messaging, the fast peer-to-peer trip and interlock signaling between bays. A relay an attacker controls is not just one bricked device — it is a trusted publisher on the station bus, able to inject or suppress GOOSE trips and ripple the compromise outward. Engineering access and the GOOSE domain belonging to the same flat network is the precondition that converts one authenticated upload into a substation-wide event.

On the protection side — IEC 60255 and the dependability of the function. A protection relay is qualified as a product to the IEC 60255 series, but the deeper point is functional: protection is a risk-reduction function for the primary plant, and its two failure directions are both hazards. Failure to trip (the relay does not see a real fault, or has been bricked) lets a fault persist — equipment damage, fire, arc-flash exposure. Spurious trip (the relay is re-parameterized to see faults that are not there) drops load and can destabilize the network. CVE-2025-40808 puts both directions within reach of an authenticated file: replace or corrupt the firmware and the relay goes dark; alter the configuration and the protection characteristic moves. The discipline that contains this is the same one a functional-safety engineer would recognize from any other domain — the integrity of a risk-reduction function must not depend on a single access-controlled channel, and the loss of any one protective device must be covered by an independent backup. Power systems already build that backup as a matter of protection philosophy: local backup, breaker-failure protection, remote zone-2/zone-3 reach. The cyber question is whether that independence survives a common-mode compromise of the engineering path — and that is exactly what most substation threat models never wrote down.

The US regulatory backstop — NERC CIP. For bulk-electric-system assets this is not optional hygiene. The "authenticated, adjacent" framing collides directly with CIP-005 (electronic security perimeter and the control of interactive remote access — the jump-host and VPN path the attacker rides), CIP-007 (ports and services, security-event monitoring, and patch management — the discipline that gets v9.90/v10.00 onto the relay and watches for the upload), and CIP-010 (configuration change management and the integrity baseline — the control that would notice firmware or settings changing out of band). CIP-010's baseline-and-monitor requirement is the closest thing the regulation has to "would you even know if the relay were reflashed," and for most asset owners the honest answer is the finding.

Stated plainly: IEC 62443 says the relay should validate its inputs and verify its own firmware; IEC 61850 and protection philosophy say no single relay's compromise should be able to defeat fault clearing; and NERC CIP says you must perimeter the engineering access and detect the change. A design that signs its firmware, isolates DIGSI 5 to its own conduit, and keeps backup protection independent of the engineering path satisfies all three. A flat substation LAN with shared engineering credentials and unsigned config satisfies none, and only looks fine because no one has uploaded the file yet.

3. A worked snippet

IEC 62443-3-2 style threat / risk row

| Field | Value | |---|---| | Asset | SIPROTEC 5 line-protection relay (e.g. 7SA8 distance), station-bus connected, GOOSE publisher/subscriber; DIGSI 5 engineering access enabled | | Threat | Authenticated arbitrary file upload over DIGSI 5 (CVE-2025-40808, CWE-434) to overwrite firmware or alter protection settings | | Attack vector | Adjacent network — compromised engineering workstation, shared/stolen DIGSI 5 credential, contractor laptop, or jump host with station-network reach | | Vulnerability | Upload handler accepts arbitrary file type/name/destination; no integrity verification of firmware/config beyond session authentication | | Consequence (availability) | Relay bricked — permanent DoS; protection function offline until device is reflashed/replaced | | Consequence (integrity) | Protection characteristic silently moved: failure-to-trip on a real fault, or spurious trip dropping load; forged/suppressed GOOSE on the station bus | | Likelihood | Medium-High — public CVE, low complexity once authenticated, and authentication is routinely satisfied in OT practice | | Unmitigated risk | High (grid impact dominates the Medium CVSS base) | | Treatment | Input allow-list + signed firmware/config + isolated engineering conduit + independent backup protection (see requirements) |

Fault tree — top event: line fault not cleared within coordinated time

TOP: Line fault persists past coordinated clearing time
        │  (AND — both must hold)
        ├── Primary relay protection defeated
        │       │ (OR)
        │       ├── Relay bricked by malicious upload (CVE-2025-40808) [permanent DoS]
        │       ├── Protection settings altered so fault is not seen [integrity attack]
        │       └── Firmware replaced; trip logic disabled/subverted
        │
        └── Backup protection cannot cover the gap
                │ (OR — any one defeats independence)
                ├── Backup relay shares the DIGSI 5 conduit / same credentials
                ├── Backup characteristic was re-parameterized in the same session
                ├── Breaker-failure / bus protection rides the same compromised GOOSE
                └── No out-of-band integrity baseline to detect the change in time

The top gate is an AND on purpose. An attacker bricking one relay is an availability incident — a forced outage, costly but bounded — provided the backup protection is genuinely independent. It becomes a fault-not-cleared hazard only when the right branch is also true, and that right branch is an architecture and key-management decision made long before any CVE existed.

FMEA excerpt (S / O / D with AIAG-VDA-style Action Priority)

| Item / Function | Failure mode | Effect | S | O | D | AP | Action | |---|---|---|---|---|---|---|---| | SIPROTEC 5 firmware integrity | Malicious firmware uploaded via DIGSI 5 | Relay bricked or trip logic subverted | 9 | 4 | 6 | High | Signed firmware + secure boot; reject unsigned image regardless of session | | Protection settings integrity | Settings re-parameterized in authenticated session | Failure-to-trip or spurious trip | 9 | 4 | 7 | High | Out-of-band settings baseline (CIP-010); dual-approval setting changes | | Engineering conduit | DIGSI 5 reachable from IT / shared creds | Attacker reaches relay with valid login | 8 | 5 | 4 | High | Dedicated engineering zone/conduit; per-user creds; MFA on remote access | | Backup protection independence | Backup defeated by same compromise | Fault not cleared by any device | 9 | 3 | 5 | High | Independent backup device, credentials, and trip path; hardwired BFI |

Severity 9 reflects a transmission/distribution protection deployment where failure-to-trip exposes equipment and people. If a given relay protects nothing whose loss matters — a lab bench, a de-energized asset — drop S accordingly, but then write down, and sign, why no consequential protection rides that device.

4. Derived requirements (excerpt)

Stable IDs, traceable to the clauses above.

REQ-PROT-005 is the one that closes the loop and the one most programs skip. The exploit is public and, once authenticated, trivial — so the failure condition is also a repeatable bench test: push a disallowed file, confirm it is refused; then take the primary relay down and prove the backup still clears the fault. The only reason that sequence first runs on an energized bus instead of a test bench is that nobody wrote the test.

5. What the headline really tells us

Read the security version and it is "Medium-severity authenticated file upload in a Siemens relay, patch available." Read the engineering version and it is two missing artifacts on the most safety-relevant device in the substation.

The first missing artifact is a firmware-integrity guarantee that does not depend on the engineering session. The allow-list Siemens added is the right move and the wrong stopping point: it tightens input validation, but it leaves the relay trusting whatever a valid login uploads. The control that actually matches the consequence is signed firmware and settings with secure boot, so that "authenticated" never silently becomes "authorized to rewrite the protection function." Authentication answers who is talking; only integrity verification answers should the relay run this — and for a device that trips a transmission breaker, that second question is the whole game.

The second missing artifact is a protection-independence claim that survives a common-mode cyber compromise. Power engineers have always built backup protection; what the DIGSI 5 path exposes is that the backup is only as independent as its credentials, its conduit, and its GOOSE domain. If the same authenticated session, the same flat network, and the same shared password reach both the primary and its backup, the redundancy that protection philosophy assumes is quietly gone — defeated not by two independent failures but by one upload. Writing that independence down, separating the keys and the conduits, and proving it on the bench is the difference between an attacker forcing an outage and an attacker defeating fault clearing.

Neither fix needs a new standard. IEC 62443, IEC 61850, IEC 60255, and NERC CIP already say everything that needs saying — validate the input, sign the firmware, perimeter the engineering access, keep the backup independent, and baseline the configuration so you would notice the change. They just do not fill themselves out. The discipline of signing the image, drawing the engineering conduit, and running the brick-to-backup-clear test is what keeps the next CVE on this relay family a maintenance ticket instead of a fault that nobody cleared.

— Jherrod Thomas, The Lion of Functional Safety™

Sources