CVE-2026-72895

Executive Summary

CVE-2026-72895 is a UEFI Secure Boot trust-anchor weakness affecting multiple Siemens SIMATIC industrial PC families (BX-21A, RW-543A, IPC227G, IPC277G, IPC277G PRO, IPC327G, IPC377G). A BIOS vendor test key is embedded in the UEFI Secure Boot key database (db/PK), meaning the platform's firmware trusts signatures produced by a non-production test signing key. A local attacker with physical or administrative access can boot an operating system or UEFI application signed with that test key, bypassing Secure Boot even when it is enabled, with potential total loss of confidentiality, integrity, and availability (CVSS 7.7). No public PoC, exploit code, or Nuclei template exists; the CVE is not in CISA KEV and has no EPSS score.

Technical Analysis

UEFI Secure Boot works by validating the signatures of boot-time executables (bootloaders, DXE/UEFI applications) against keys held in firmware key databases — the Platform Key (PK), Key Exchange Key (KEK), and the authorized signature database (db). The db typically contains certificates from the OS vendor (e.g., Microsoft) and, in some cases, OEM/ODM keys. When a signing key is present in db, any binary whose signature chains to that key is trusted by the firmware and permitted to execute at boot regardless of whether it is a legitimate production OS loader.

CWE-1394 ("Use of Default Cryptographic Key") is the assigned weakness class. The NVD description states plainly that a BIOS vendor test key is present in the UEFI Secure Boot key database. This is a provisioning/lifecycle defect: a development or manufacturing test certificate that should never have shipped was enrolled into the production Secure Boot db. Because trust is anchored at the firmware level, the defect is not remediable through OS-level tooling — it is a key-database contents problem that must be corrected by the BIOS/firmware vendor or reset by the device owner.

Attack surface and preconditions:

• Attack vector is Local (AV:L): requires either physical access to the machine or a privileged/administrative foothold capable of driving firmware operations such as rebooting into a controlled boot image or updating/clearing Secure Boot key databases.
• Complexity is High (AC:H): the attacker must possess — or have to reconstruct — the private component corresponding to the vendor test key, or obtain already-signed artifacts produced during that key's lifecycle. This is not a straightforward "toggle a setting" attack; it depends on obtaining test-key-signed material.
• Privileges Required are None (PR:N) at the OS layer, but the physical/administrative access requirement is captured by AV:L and UI:R. User Interaction is Required (UI:R): a reboot or manual boot selection at the firmware boot menu is a common manifestation.
• Scope is Changed (S:C): the compromise crosses from the OS/user domain into the platform firmware/root-of-trust domain. This is why the score reaches 7.7 despite the local vector — the security authority being violated is the boot chain itself, not merely an application.

Impact subscores are Confidentiality:High / Integrity:High / Availability:High. Once a test-key-signed bootloader or UEFI application runs, an attacker operates below the effective boundary of OS security controls. Typical consequences include disabling kernel/OS code-signing enforcement, installing persistent bootkits, modifying the OS before it initializes its own protections, and defeating measured-boot attestation used by industrial control deployments.

Because the description gives no file paths, key GUIDs, function names, or db/PK entries, the exact byte-level identity of the test key, its enrollment provenance, and the firmware module responsible cannot be stated from the available data. What is verifiable: the trusted key exists in the shipped UEFI Secure Boot database, and trust flows to any binary it signs.

Exploitation Scenarios

No public PoC, exploit code, or Nuclei template is available for CVE-2026-72895. The attack chain below is described at the vulnerability-class level; specific implementation details (key GUIDs, signed binary names, firmware module paths) are not present in the NVD description and are deliberately not invented.

1. Reconnaissance / target identification. The attacker identifies a target device from the affected SIMATIC IPC families and confirms firmware revision is below the fixed build (BX-21A < V31.01.13, RW-543A < V1.1.4, IPC227G/277G/277G PRO/327G/377G < V28.01.15). This can be done locally via firmware inventory from the OS, vendor tooling, or physically at the boot splash. Network-side discovery of exposed Siemens SIMATIC web interfaces can pre-screen candidate assets, though the actual exploitation step is local. A determination is then made as to whether the vendor test key is present in Secure Boot db — for example by inspecting the enrolled key database from an administrative session.

2. Trigger of the specific flaw class. The flaw is not "triggered" in the memory-corruption sense; it is a trust condition that is already present. The attacker obtains an operating system image or UEFI application that has been signed by the BIOS vendor test key (through leakage, a signed artifact obtained from the supply chain, or reconstruction during the key's usable window). The attacker reboots the device and lets Secure Boot perform its normal signature validation. Because the signing certificate is enrolled in db, firmware treats the test-key-signed artifact as trusted and loads it — even though Secure Boot is reported as enabled and enforcing.

3. Payload / execution method. The test-key-signed artifact executes at pre-OS/UEFI stage. Depending on what the artifact is, it can be a bootloader that then launches an unsigned or mismatched kernel with protective features suppressed, or a UEFI application that manipulates boot variables, patches in-memory firmware structures, or drops a persistent pre-OS component before handing control to the OS. The defining property is that no Secure Boot violation occurs because the trust check passes against the vendor test key.

4. Post-exploitation impact. Having executed below the OS security boundary, the attacker can install persistent boot-level code that survives OS reinstallation, weaken or disable kernel code-signing/hypervisor protections for a subsequent stage, tamper with the boot chain to facilitate credential theft or lateral movement, and defeat attestation used to assert platform integrity. Given the affected products are industrial PCs, the realistic downstream effects include manipulation of HMI/SCADA-adjacent workloads, denial of service to control functions, and long-dwell firmware persistence in OT environments where reflash cycles are infrequent. The CVSS subscores (C:H/I:H/A:H, S:C) reflect this full loss of confidentiality, integrity and availability of the device.

Impact Assessment

Business impact centers on loss of the platform root of trust on ruggedized industrial PCs commonly deployed on factory floors, in process control cabinets, and at distributed edge/OT sites. Once Secure Boot can be bypassed via a trusted test key:

• Confidentiality: High — a pre-OS attacker can access disk and memory below OS access controls; industrial data, engineering credentials, and control variables may be exposed.
• Integrity: High — boot loaders, kernels, and potentially safety-relevant configuration can be modified without triggering Secure Boot enforcement.
• Availability: High — boot-chain tampering can render devices unbootable, or a compromised boot path can be used to disrupt the workloads the IPC runs.
• Scope: Changed — the authority violated (firmware root of trust) is distinct from the component carrying the vulnerable key database.

Blast radius is bounded by the High attack complexity and the Local vector: exploitation requires physical access or administrative control and possession of test-key-signed material. It is therefore most relevant as a persistence and defense-evasion primitive for a motivated insider, a supply-chain-injected signed artifact, or an attacker who has already obtained either physical access to an exposed OT device or an administrative foothold on it. Devices that never had the test key enrolled, or that are updated to the fixed firmware builds, are not affected by the described condition. No exploit-in-the-wild evidence, CISA KEV listing, or public PoC currently exists; prioritization should be driven by OT asset exposure and the difficulty of physically securing unmanned industrial cabinets, not by an imminent mass-exploitation signal.

Detection Guidance

Detection is difficult because the exploitation event is a firmware-level boot action and does not generate conventional application logs. The following rules are best-effort detections that pivot on the observable artifacts of the boot-chain trust anomaly and its downstream effects. Because the NVD description provides no filenames, key GUIDs, or byte patterns, the rules below are generic to the vulnerability class (test-key-signed boot artifacts, Secure Boot state changes, abnormal boot events) and are labeled as such.

Sigma Rule

title: Siemens SIMATIC IPC Secure Boot Test Key Abuse - Boot Chain Anomaly
id: 8f4c1a2e-7b91-4d3a-9c2f-7e6a1b9d0c55
status: experimental
description: >
  Detects conditions consistent with abuse of a BIOS vendor test key enrolled in the
  UEFI Secure Boot db on affected Siemens SIMATIC IPC families. Pivots on attempts to
  enumerate/alter Secure Boot key databases and on suspicious pre-OS reboot activity.
  Generic to the vulnerability class; no specific filenames are known for CVE-2026-72895.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-72895
author: Threat Intelligence
date: 2026/01/01
logsource:
  category: process_creation
  product: windows
detection:
  selection_keys:
    CommandLine|contains:
      - 'db'
      - 'KEK'
      - 'PK'
      - 'SecureBoot'
      - 'SbConfig'
  selection_tools:
    Image|endswith:
      - '\bcdedit.exe'
      - '\powershell.exe'
      - '\reg.exe'
    CommandLine|contains:
      - 'SecureBoot'
      - 'Set-SecureBootUEFI'
      - 'Get-SecureBootUEFI'
      - 'Update-SecureBootUEFI'
  selection_reboot:
    Image|endswith: '\shutdown.exe'
    CommandLine|contains:
      - '/r'
      - '/fw'
  condition: (selection_tools and selection_keys) or selection_reboot
falsepositives:
  - Legitimate firmware maintenance or Secure Boot key rotation by IT
  - Vendor BIOS update tooling
level: medium
tags:
  - attack.defense_evasion
  - attack.t1542.001
  - cve.2026.72895

YARA Rule

rule CVE_2026_72895_SecureBoot_TestKey_Artifact
{
    meta:
        description = "Detects PE/EFI boot artifacts weakly associated with test-key-signed UEFI images. Generic heuristic only; no verified byte pattern is known for CVE-2026-72895."
        author = "Threat Intelligence"
        date = "2026-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-72895"
        cve = "CVE-2026-72895"
        severity = "high"

    strings:
        $mz = { 4D 5A }
        $efi_sig = { 0E 1F 00 }                        // EFI application subsystem marker heuristic
        $secureboot = "SecureBoot" ascii wide nocase
        $pk = "PlatformKey" ascii wide nocase
        $kek = "KeyExchangeKey" ascii wide nocase
        $db = "SignatureDatabase" ascii wide nocase
        $teststr1 = "TEST" ascii wide
        $teststr2 = "DEV" ascii wide
        $teststr3 = "SAMPLE" ascii wide

    condition:
        $mz at 0 and
        ( $secureboot or $pk or $kek or $db ) and
        any of ( $teststr* )
}

Note: this YARA rule is a coarse heuristic for hunting potentially test-signed boot components in staging/shared locations. It does not verify cryptographic trust and will not reliably distinguish a genuine test-key-signed artifact from benign strings. It should be used only for triage on file shares, USB staging areas, or firmware distribution repositories.

Suricata IDS Rule

alert http any any -> any any ( \
  msg:"CVE-2026-72895 Siemens SIMATIC IPC - possible firmware/tool download or Secure Boot key management activity"; \
  flow:to_server,established; \
  http.method; content:"GET"; \
  http.uri; content:"SIMATIC"; nocase; \
  http.uri; content:"firmware"; nocase; \
  reference:cve,2026-72895; \
  classtype:attempted-admin; \
  sid:202672895; rev:1; )

alert tcp any any -> any any ( \
  msg:"CVE-2026-72895 Siemens SIMATIC IPC - SMB transfer of possible boot artifact sample"; \
  flow:to_server,established; \
  content:"|FF|SMB"; offset:4; depth:4; \
  content:".efi"; nocase; within:200; \
  reference:cve,2026-72895; \
  classtype:misc-activity; \
  sid:202672896; rev:1; )

These signatures are network-opportunistic only. The exploitation event is local to the firmware and does not traverse the network; the rules target adjacent activity (firmware/tooling retrieval, transfer of .efi staged artifacts) that often accompanies enabling this class of attack.

Elastic Detection

process where event.type == "start" and
process.name in ("bcdedit.exe", "reg.exe", "powershell.exe", "SbConfig.exe") and
(
  process.command_line : "*SecureBoot*" or
  process.command_line : "*Set-SecureBootUEFI*" or
  process.command_line : "*Get-SecureBootUEFI*" or
  process.command_line : "*Update-SecureBootUEFI*" or
  process.command_line : "*db*" or
  process.command_line : "*KEK*" or
  process.command_line : "*PK*"
)

This rule flags enumeration or modification of Secure Boot key state and firmware boot configuration used in the execution chain. Investigate correlation with subsequent near-term reboots, firmware flashes, or the appearance of new .efi artifacts on the host.

Splunk SPL Query

index=endpoint OR index=sysmon EventCode IN (1,11)
(
  (CommandLine="*SecureBoot*" OR CommandLine="*Set-SecureBootUEFI*" OR CommandLine="*Get-SecureBootUEFI*" OR CommandLine="*bcdedit*" OR CommandLine="*SecureBootUEFI*")
  OR
  (TargetFilename="*.efi" OR TargetFilename="*.efi.signed")
)
| eval risk=case(
    match(CommandLine,"(?i)secureboot|bcdedit|securebootuefi"), "high",
    match(TargetFilename,"(?i)\.efi$"), "medium",
    true(), "low")
| stats count min(_time) as first_seen max(_time) as last_seen by host, user, Image, CommandLine, TargetFilename, risk
| where count > 0
| sort - risk, - count

Wazuh OSSEC Rule

<group name="siemens,secureboot,cve-2026-72895,">
  <rule id="202672" level="10">
    <decoded_as>windows_eventchannel</decoded_as>
    <field name="win.system.eventID">^1$</field>
    <field name="win.eventdata.commandLine">(?i)(secureboot|Set-SecureBootUEFI|Get-SecureBootUEFI|bcdedit)</field>
    <description>CVE-2026-72895: possible Secure Boot key database enumeration or modification (Siemens SIMATIC IPC class)</description>
    <mitre>
      <id>T1542.001</id>
    </mitre>
    <group>windows,sysmon,</group>
  </rule>

  <rule id="202673" level="8">
    <decoded_as>windows_eventchannel</decoded_as>
    <field name="win.system.eventID">^11$</field>
    <field name="win.eventdata.targetFilename">(?i)\.efi$</field>
    <description>CVE-2026-72895: new UEFI boot artifact written to disk, possible boot-chain staging</description>
    <mitre>
      <id>T1542.001</id>
    </mitre>
    <group>windows,sysmon,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations (do not replace patching):

• Enforce physical security for affected SIMATIC IPC devices. Because exploitation requires physical or administrative access, restricting physical access to unmanned cabinets, control rooms, and edge enclosures directly raises the exploitation cost.
• Where the platform workflow allows, put the device into a Custom Mode / Setup Mode and explicitly reset the Secure Boot key database to a clean state, clearing the vendor test key. This must be validated against the device's firmware behaviour for the specific model; if the platform re-enrolls default keys containing the test key after reset, this mitigation is ineffective and only firmware replacement resolves the issue.
• Restrict local administrative rights. The vector is local; reducing which accounts can reboot the device, change firmware settings, or update firmware limits who can attempt the attack.
• Enable boot logging and integrity monitoring (measured boot / TPM-based attestation) where the installed firmware supports it, and alert on boot-measurement discrepancies.
• Network-isolate affected IPCs and limit remote-access channels (RDP, VNC, remote KVM/console) that could give a remote attacker the "administrative" foothold combined with a reboot to satisfy the AV:L/UI:R conditions.

2. Patch / upgrade steps:

• Track the vendor advisory for these models. The fixed builds referenced in the NVD description are: SIMATIC IPC BX-21A V31.01.13 or later; SIMATIC IPC RW-543A V1.1.4 or later; SIMATIC IPC227G / IPC277G / IPC277G PRO / IPC327G / IPC377G V28.01.15 or later. Confirm these exact versions against the official Siemens ProductCERT/Siemens Security Advisory before deploying, as this report derives them solely from the NVD narrative.
• Apply the vendor BIOS/UEFI update through the supported firmware update path. Do not distribute firmware images over untrusted channels.
• After flashing, re-verify Secure Boot status and re-enumerate the enrolled key database to confirm the test key is no longer present.
• Given patch confidence 0/4, treat any current claim of a fix as unverified until the vendor advisory is authoritative.

3. Long-term hardening:

• Adopt firmware/Secure Boot configuration verification as a standing control: baseline the enrolled PK/KEK/db contents across the fleet and alert on unexpected keys.
• Include pre-OS boot chain integrity in change management for OT assets; treat firmware version as a first-class asset attribute.
• Require firmware signing-key hygiene from suppliers: contractual assurance that test/development keys are never enrolled in production Secure Boot databases.
• Use TPM-backed measured boot and attestation for high-value industrial controllers so a test-key bypass is detectable even when Secure Boot reports "enabled."
• Segment industrial networks from IT and from the internet; reduce opportunities for an attacker to obtain the administrative foothold needed to reboot and re-provision a device.

References

• NVD — CVE-2026-72895: https://nvd.nist.gov/vuln/detail/CVE-2026-72895
• MITRE CWE-1394 — Use of Default Cryptographic Key: https://cwe.mitre.org/data/definitions/1394.html
• MITRE ATT&CK T1542.001 — Pre-OS Boot: System Firmware: https://attack.mitre.org/techniques/T1542/001/
• Siemens ProductCERT / Siemens Security Advisories (vendor advisory portal for SIMATIC IPC firmware): https://www.siemens.com/global/en/products/services/cert.html
• FIRST EPSS — not yet scored for CVE-2026-72895 (no value available at time of writing)
• CISA Known Exploited Vulnerabilities catalog — CVE-2026-72895 not listed

No public proof-of-concept, exploit code, or Nuclei template is known for CVE-2026-72895. No threat-actor campaign or in-the-wild exploitation evidence is associated with this CVE in the provided data.