Siemens Software Center: a signed executable loaded the attacker’s DLL

Siemens advisory dated October 15, 2026, exploit confirmed on October 19. Siemens ProductCERT describes a campaign that used a real signed copy of Siemens Software Center, accompanied by attacker-provided DLLs in the same folder. The vulnerable version looked for auxiliary libraries in an insufficiently controlled path and loaded these files during startup. CVE-2026-110936 is therefore not a compromise of the Siemens update channel: it is the abuse of a loading decision made by a legitimate program.

What a signature guarantees, and what it does not guarantee

Signing an executable allows you to verify the publisher and its integrity. It does not automatically sign all files present in the directory where the user runs it. On Windows, when a program requests a DLL by name without establishing a secure origin, the loader searches a series of locations. If a folder controlled by the attacker intervenes in this search, a DLL with the expected name can be loaded under the identity of the program. The malicious code then executes with its privileges.

In the vulnerability advisory, Siemens formally qualifies the condition as local and indicates that an authenticated actor capable of placing a DLL in the searched path can achieve code execution. In the observed campaign, the practical context was different: the attackers distributed the signed program and their files together, then pushed the user to execute this package using a ClickFix maneuver. This social engineering explains how they satisfied the placement condition without having to alter the Siemens binary itself. This malicious distribution must be distinguished from the local CVSS scenario of the CVE.

The exact trust boundary

The decisive moment is not the download of the signed software, but the library load call. Version 3.5.8.7, described by Siemens as the version used by the campaign, loaded auxiliary files from its own folder without sufficiently verifying what they were. A folder chosen by the attacker thus becomes a source of code for a trusted process. The file names observed in the campaign and the indicators are in the Siemens report, but the article does not need to infer that all DLLs placed next to the binary would have the same effect: the behavior depends on the name actually searched for.

An authorized audit can use a module loading monitor to note the path of each DLL opened by the program and then compare the behavior in a protected system folder and in an editable folder. The negative test consists of showing that the corrected program refuses or avoids the foreign DLL. The danger is also measured by the origin of the process: a Siemens executable launched from AppData on a computer where the software was not installed is a different signal from the same file signature in the official installation directory.

Verification and response

Siemens sets the corrected threshold to 4.0.9.8 and indicates that existing installations update on the next launch. It specifies that no Siemens system, product or update channel was compromised to its knowledge. Teams must therefore check the version, location of the launched binary, adjacent DLLs, and autostart mechanisms. Detection limited to the signature of the executable will not distinguish the hostile package from an authentic copy.

This case explains why “signed file” and “safe process” are not synonymous: trust in the binary must be extended to the dependencies it loads and the directory from which it is executed.

Primary sources: Siemens notice SSA-580366, Siemens active operation report.