Keeping Your Substation More Secure

Four Vulnerabilities Fixed in Siemens SICAM S8000 (SSA-229470)

Vendor advisory: Siemens SSA-229470 — “Multiple Vulnerabilities in SICAM 8 Products Before V26.20”

Note: This writeup covers only the four issues fixed in SICAM 8 V26.20 and published in SSA-229470. It reflects analysis of a V26.10 lab build and was coordinated with Siemens ProductCERT under responsible disclosure.

TL;DR

Over a research engagement against Siemens’ SICAM S8000 V26.10 power-automation platform, North Echo reported a set of authenticated and unauthenticated security issues to Siemens ProductCERT. Siemens fixed them in V26.20 and published SSA-229470 with four CVEs:

The through-line: debug/diagnostic functionality that shipped into production, insecure-by-default configuration, and a container model that removes the isolation you’d expect to contain any of it.

Background: what SICAM S8000 is

SICAM S8000 is part of Siemens’ SICAM 8 family — a software-defined RTU / substation automation platform used in electrical grids. It runs the SICORE base system on Linux and hosts its functionality as a set of containerized applications:

• A web management interface (SICAM WEB, HTTPS) backed by FastCGI services, driving an XML command API under /sicweb-ajax/*.
• A collection of protocol handlers, each in its own container — IEC 60870-5-104 (ETI4), IEC 61850/MMS (ETI5), DNP3 (DNPMI0), Modbus TCP (MODMI0), and OPC UA (OPCUA00).
• System services — MQTT broker, process management, configuration, etc.

Signals flow between the field devices and these handlers over an internal MQTT-based bus. Understanding that architecture matters, because several of these findings are only as severe as the isolation model around them — and that model turned out to be very thin.

Disclosure timeline

Siemens published roughly 12 weeks after first contact — inside a standard 90-day window.

CVE-2026-54801 — Privilege escalation in the SICAM WEB management API

CVSS 4.0: 8.6 (High)

The SICAM WEB interface uses a role-based access control model — administrators, and lower-privileged roles such as security/user-management operators. The intent is that a non-admin role can manage users without being able to become the built-in administrator.

That boundary did not hold. A predefined non-admin role with user-management rights could act against the built-in administrator account — effecting an administrative credential change and thereby escalating to full administrative control of the device management plane. In Siemens’ words, “insufficient credential validation permits authenticated users to escalate privileges through administrative account modifications.”

Why it matters: the SICAM WEB plane is where device configuration, resets, and operational control live. Collapsing the operator→admin boundary means any account provisioned for limited user administration is effectively an admin. In an environment where roles are handed out to multiple operators, that is a meaningful trust-boundary failure.

(Full request/response detail was provided to Siemens in the coordinated evidence package.)

CVE-2026-54799 — Firmware signature verification can be switched off by a debug command

CVSS 4.0: 8.4 (High)

SICAM S8000 firmware packages use a two-layer integrity model:

1. An ECDSA signature (pim.sig) over a SHA-256 manifest (pim.meta), verified against an embedded Siemens SICAM root certificate.
2. SHA-256 hash verification of the individual files listed in the manifest.

The problem is in how a signature failure is handled. In the installer /ies/sc/instfpkg.sh:

# check signature
${IES_SIG_CHECK}
if [ $? -ne 0 ]; then
   inst_error "1" "$1" "Signature Error for $1"
   #return 1                              # <-- the hard fail is commented out
   if [ -f "/tmp/sig_ignore" ]; then
      inst_log "Ignore wrong signature for $1"
   else
      return 1
   fi
else
   inst_log "Signature OK for $1"
fi

The unconditional return 1 on a bad signature is commented out. The sole remaining gate is the presence of a file, /tmp/sig_ignore. And a debug utility that ships in production, /usr/bin/deb, creates exactly that file:

"sigoff")
    echo 1 >/tmp/sig_ignore
    ;;

Its own help text advertises the behavior:

deb sigoff ........... Disable signature check

Run deb sigoff, and the installer will accept a firmware package with an invalid ECDSA signature. Layer 2 (hashes) still runs but is meaningless — an attacker who supplies the malicious files also supplies their hashes in the manifest. The result is installation of arbitrary unsigned firmware and persistent code execution.

Verified on the lab build:

$ deb sigoff && ls -la /tmp/sig_ignore
-rw-r--r--  1 root  root  2  /tmp/sig_ignore

The amplifier: container isolation

On its own, this needs local shell access. What makes it worse is the container model around it. On the V26.10 lab build, protocol-handler and system containers ran with isolation effectively removed:

• --privileged, with all Linux capabilities (CapEff: 0000003fffffffff)
• Shared host PID, IPC, and network namespaces
• The entire host filesystem bind-mounted
• No user-namespace remapping (container root == host root)

From inside a container, /etc/shadow was readable, host processes were visible and signalable, and host kernel modules were listed. In other words, code execution in any container was equivalent to root on the host — from which deb sigoff is one command away. Siemens’ advisory captures this as the firmware-signature CVE; the isolation weakness is the reason a contained service compromise doesn’t stay contained.

Fix direction (and what V26.20 addresses): remove the debug bypass from production, make signature failure fatal unconditionally, and tighten the container privilege/namespace/mount posture.

CVE-2026-54800 — OPC UA server: insecure by default

CVSS 4.0: 6.3 (Medium)

The OPC UA server (OPCUA00, built on open62541) shipped with every security mechanism disabled by default:

<ParameterType parameterTypeId="enable_security_profiles">
    <Bool defaultValue="false">          <!-- security OFF -->

<ParameterType parameterTypeId="certificate_verification_accept_all">
    <Bool defaultValue="true">           <!-- accept ANY certificate -->

With enable_security_profiles = false, server startup takes the UA_ServerConfig_setDefault() path — which offers only SecurityPolicy#None (no encryption, no signing), enables the Anonymous user-token policy, and installs a default access control that grants any activated session full rights. (And even if security is turned on, certificate_verification_accept_all = true makes the server accept any client certificate.)

Crucially, the process-control variables are writable. Command (CMD) and setpoint (SPC) signals are created at AccessLevel = 3 (read + write):

// Signal type 0x32 (CMD): AccessLevel = 3  (read + write)
// Signal type 0x35 (SPC): AccessLevel = 3  (read + write)

So the end-to-end attack is simply:

TCP/4840 (no TLS) → OpenSecureChannel (SecurityPolicy#None)
  → ActivateSession (Anonymous, accepted)
  → Browse the namespace
  → Read voltages, currents, breaker states
  → Write circuit-breaker commands and voltage setpoints

Replicating the exact UA_ServerConfig_setDefault() configuration on a stand-in open62541 server reproduced anonymous writes to both a command and a setpoint variable:

[RESULT] *** ANONYMOUS WRITE TO COMMAND VARIABLE SUCCEEDED ***
[RESULT] *** ANONYMOUS WRITE TO SETPOINT SUCCEEDED ***
warn/server  AccessControl: Unconfigured AccessControl. Users have all permissions.
info/server  AccessControl: Anonymous login is enabled

What compounded this was the documentation gap: at the time of analysis, neither the Communication manual (DC8-134-2) nor the Administrator Security manual (DC8-131-2) gave any guidance to turn OPC UA security on before deployment. An operator following the manuals would stand up a substation OPC UA server that accepts anonymous writes to breaker commands — a direct path to unauthorized process control (MITRE ATT&CK for ICS T0855 / T0836) with real physical-safety implications.

Fix direction: secure-by-default (security profiles on, accept-all off, no anonymous write to control signals) plus explicit security guidance in the manuals.

CVE-2026-54798 — Debug interface over HTTP → web-process DoS

CVSS 4.0: 7.1 (High)

The SICAM WEB backend exposed debug/diagnostic functionality through HTTP endpoints that should not have been reachable in production. An authenticated user — including a low-privilege role — could reach this diagnostic surface and drive the web management process into a crash, taking down the management interface (denial of service). Related diagnostic endpoints also exposed process/debug information to roles that had no business seeing it.

Why it matters: losing the SICAM WEB plane means losing the operator’s window into and control over the device’s management functions. It’s “only” a DoS, but on an availability-critical substation asset, remote-triggerable loss of the management interface by a minimally-privileged account is not a small thing — which is why the CVSS 4.0 score lands at 7.1.

(Endpoint specifics and the crash reproduction were provided to Siemens in the coordinated evidence package.)

The common thread

None of these are memory-corruption exotica. They’re logic- and configuration-level failures:

• Debug code in production — deb sigoff (CVE-2026-54799) and the HTTP debug interface (CVE-2026-54798) are both diagnostic conveniences that never should have shipped reachable.
• Insecure defaults — the OPC UA server (CVE-2026-54800) is safe only if an operator knows to change settings the manuals didn’t tell them to change.
• Broken trust boundaries — the RBAC escalation (CVE-2026-54801) and the flat container model both erase separations that were nominally in place.

For ICS platforms, this class of issue tends to matter more than a clever heap overflow: it’s reachable by design, needs little sophistication, and the blast radius is a power substation.

Remediation

All four issues are fixed in SICAM 8 / SICAM S8000 V26.20, available from Siemens Industry Online Support. Operators should update per SSA-229470. As always for ICS: keep management and OPC UA interfaces off routable networks, segment per IEC 62443, and restrict access to the substation network.

Coordination & credit

These findings were reported to and fixed by Siemens ProductCERT under coordinated disclosure, resulting in SSA-229470. Thanks to the ProductCERT team for professional handling and a timely fix. Full CVE details are in the Siemens advisory.

North Echo Security Research performs independent, logic-level vulnerability research on ICS/OT and edge platforms. — northecho.dev