CVE-2026-110021 in PLCnext Engineer
Summary
by MITRE • 11/04/2026
PLCnext Engineer checks GSDX manifest reference digests but does not cryptographically verify the XML `SignatureValue` over canonicalized `SignedInfo`. An unauthenticated local attacker can modify signed GSDML content, update its manifest digest, retain the public certificate data, and leave an invalid nonempty `SignatureValue`. PLCnext Engineer prior to 2026.6 reports the package as `Valid` and selects the modified device description for import under the default policy.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability in Siemens PLCnext Engineer versions prior to 2026.6 represents a critical failure in cryptographic verification within the process of importing GSDML (General Station Description Markup Language) packages, which are used to define fieldbus devices and their communication parameters for programmable logic controllers. The core technical flaw lies in the application's handling of XML digital signatures associated with these device description files. Specifically, while the software correctly validates the integrity of the manifest file by checking its digest against a reference value stored within it, it fails to perform a rigorous cryptographic verification of the actual XML signature over the canonicalized SignedInfo element. This means that although the system checks if the package metadata matches expected hashes, it does not cryptographically prove that the signed content has remained unaltered since the signature was generated using the private key corresponding to the public certificate included in the package.
This architectural weakness allows an unauthenticated local attacker with access to the file system or input mechanisms of PLCnext Engineer to perform a sophisticated tampering attack. The attacker can modify the contents of the signed GSDML files, which dictate how the PLC interacts with external hardware devices such as sensors, actuators, or other networked equipment. After altering the device description data, the attacker updates the manifest digest to match the new content, effectively bypassing the initial integrity check. Crucially, the attacker retains the original public certificate data and leaves an invalid but non-empty SignatureValue field in place. Because PLCnext Engineer does not cryptographically verify that this signature value is mathematically valid for the modified SignedInfo block, it accepts the package as authentic. The software reports the package status as Valid, leading to the import of the maliciously altered device description under default security policies without raising any warnings or errors regarding signature validity.
The operational impact of this vulnerability is severe and potentially catastrophic in industrial control environments. By injecting a modified GSDML file, an attacker can fundamentally alter how the PLC interprets commands from field devices or sends data to them. This could result in incorrect process control logic being executed, such as opening valves that should remain closed, stopping safety-critical machinery unexpectedly, or sending erroneous sensor readings to supervisory systems like SCADA. In worst-case scenarios, this manipulation can lead to physical damage to equipment, production downtime, environmental hazards, or threats to human safety. Since the attack requires only local access and exploits a default configuration where packages are accepted as valid upon superficial checks, it serves as an effective initial vector for further compromise of the industrial control system network once inside the perimeter.
From a classification perspective, this vulnerability aligns with CWE-347: Improper Verification of Cryptographic Signature, as the application fails to ensure that digital signatures provide adequate integrity and authenticity guarantees. It also relates closely to CWE-20: Improper Input Validation, specifically in the context of XML processing where canonicalization and signature verification steps are either skipped or incorrectly implemented. In terms of offensive security frameworks, this flaw facilitates MITRE ATT&CK technique T1553.004: Subvert Trust Controls, as it involves bypassing code signing mechanisms to execute unauthorized modifications to trusted device descriptions. It can also be categorized under T1195.002: Supply Chain Compromise, given that GSDML files are often sourced from third-party vendors and imported into the engineering environment.
Mitigation strategies must focus on immediate patching and enhanced validation practices. The primary remediation is to upgrade PLCnext Engineer to version 2026.6 or later, where Siemens has addressed this cryptographic verification gap by ensuring that both manifest digests and XML signature values are rigorously validated against the provided public certificates before accepting any GSDML package. For environments where immediate patching is not feasible, administrators should implement strict file integrity monitoring on directories containing device description files to detect unauthorized modifications. Additionally, restricting local user privileges can limit an attacker's ability to inject malicious packages into the import workflow. Organizations should also enforce a policy of only importing GSDML files from verified and trusted vendors, utilizing out-of-band verification methods such as comparing SHA-256 hashes provided by the vendor against those in the package manifest before any software processing occurs.