CVE-2026-72895 in SIMATIC IPC BX-21A
Summary
by MITRE • 10/13/2026
A vulnerability has been identified in SIMATIC IPC BX-21A (All versions < V31.01.13), SIMATIC IPC RW-543A (All versions < V1.1.4), SIMATIC IPC227G / IPC277G / IPC277G PRO / IPC327G / IPC377G (All versions < V28.01.15). A BIOS vendor test key is present in the UEFI Secure Boot key database. This could allow a local attacker with physical or administrative access to the device to boot an operating system or UEFI application signed with that test key, bypassing UEFI Secure Boot protections even when Secure Boot is enabled, potentially leading to a full loss of confidentiality, integrity, and availability of the device.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The identified vulnerability resides within the Unified Extensible Firmware Interface (UEFI) implementation across several Siemens SIMATIC Industrial PC models, specifically including the IPC BX-21A versions prior to V31.01.13, the IPC RW-543A versions prior to V1.1.4, and a range of IPC series such as the IPC227G, IPC277G, IPC277G PRO, IPC327G, and IPC377G with firmware versions below V28.01.15. The core technical flaw is the presence of an unauthorized BIOS vendor test key within the UEFI Secure Boot key database. This configuration error fundamentally undermines the integrity verification mechanism that Secure Boot is designed to enforce. By retaining this test key, which was likely intended for development or manufacturing purposes but left in production firmware, the system fails to strictly validate only trusted signatures during the boot process. Consequently, any operating system image or UEFI application signed with this specific test key will be accepted by the firmware as legitimate and authorized for execution, regardless of whether Secure Boot is actively enabled by the administrator.
From an operational perspective, this vulnerability creates a severe security gap that allows for the bypassing of critical boot-time protections. A local attacker who possesses physical access to the device or administrative privileges can exploit this flaw to load malicious code at the earliest stages of system initialization. Because UEFI Secure Boot is designed to prevent unauthorized software from loading during startup, its circumvention via a known test key effectively neutralizes one of the primary defenses against rootkits and bootkit malware. The attacker does not need to compromise the firmware itself or exploit a separate vulnerability in the bootloader; they simply need to sign their malicious payload with the exposed vendor test key. This capability enables the execution of arbitrary code before the operating system security mechanisms are initialized, granting the attacker full control over the hardware environment from the very first instruction executed by the CPU.
The impact of this vulnerability is profound and aligns closely with CWE-295, which describes Improper Certificate Validation, as well as CWE-780, which refers to Use of RSA Key or PKCS1 Key in a Context that Does Not Require It for Security. The presence of an unnecessary test key violates the principle of least privilege and secure configuration management. Furthermore, this attack vector maps directly to MITRE ATT&CK technique T1542.003, known as Bootkit: UEFI/BIOS Rootkits, where adversaries establish persistence by modifying firmware or boot sectors. It also relates to T1068 Exploitation for Privilege Escalation and potentially T1059 Command and Scripting Interpreter if the loaded payload executes scripts. The successful exploitation leads to a complete loss of confidentiality, integrity, and availability. Confidentiality is compromised as the attacker can access sensitive data stored on the disk before encryption keys are fully initialized or while they are in memory. Integrity is lost because the system cannot guarantee that only authorized software has run since power-on. Availability is threatened as malicious code can disrupt normal operations or render the system unbootable if it corrupts critical boot components.
Mitigation requires immediate action to remove this security weakness from the affected devices. The primary remediation step is for Siemens to release and deploy a firmware update that removes the vendor test key from the UEFI Secure Boot database, ensuring that only keys explicitly designated for production use are retained. Administrators of these industrial control systems must prioritize applying these updates as soon as they become available. In environments where immediate patching is not feasible due to operational constraints, temporary mitigations should be considered. These may include disabling network interfaces if the device does not require remote connectivity during boot, implementing strict physical access controls to prevent unauthorized individuals from interacting with the hardware ports or BIOS settings, and monitoring for unusual behavior in system logs that might indicate an attempt to load unsigned or improperly signed code. Additionally, organizations should audit their firmware management processes to ensure that development keys are never inadvertently shipped with production-grade industrial equipment, adhering to industry standards such as IEC 62443 for security in automation and control systems which emphasize the importance of secure boot configurations and proper key lifecycle management.