Siemens confirms CVE-2026-110936 is exploited through a signed binary shipped with a malicious DLL

October 15, 2026. Siemens publishes advisory SSA-580366 for CVE-2026-110936, a DLL side-loading flaw in Siemens Software Center. October 19, 2026. The vendor confirms active exploitation and publishes indicators of compromise: attackers distribute a genuine, signed copy of the program — version 3.5.8.7 — bundled with malicious DLLs, outside official channels. October 20, 2026. CISA adds the flaw to its KEV catalog, with a federal deadline of November 3. The point that matters: a signed binary, one of the pillars of software trust, has become the delivery vehicle for the attack.

For a CISO or a fleet owner, this is not one more Siemens bulletin. It is concrete proof that code signing no longer means anything when the attacker picks the signed program they ship.

The flaw: an uncontrolled DLL search path

CVE-2026-110936 is classified CWE-427 (Uncontrolled Search Path Element). In plain terms, Software Center — the application that downloads, installs, activates and updates purchased Siemens software — loads DLLs from a search path it does not control. A local, authenticated attacker can drop a crafted DLL into a directory the program scans and gain arbitrary code execution with the application’s privileges.

The scoring shows how uncomfortable CVSS is with this class of bug. Siemens rates it 6.7 under CVSS v3.1 — “medium” — but 8.4 under CVSS v4.0, or “high.” The gap comes from the vector: the flaw itself is local (AV:L) and requires high privileges (PR:H). Yet in the real campaign, it is not an administrator who triggers the chain — it is a victim duped by a ClickFix lure into pasting a command into the Windows Run box.

The attack: bring your own signed binary

The tradecraft is the instructive part. According to Siemens, the attackers did not modify the program: “The Siemens program was not modified. The malicious code is in the DLL files the attackers supplied.” They took a genuine copy of Software Center 3.5.8.7, with a valid signature, and placed it next to their malicious DLLs. The signed binary acts as a trust lure: security tools let it through, and the system loads it without complaint.

Siemens ties the activity to the Romulus campaign, a multi-payload ClickFix delivery platform documented by Forescout Vedere Labs on October 15. Forescout identified the address 2.27.248[.]127 — the one Siemens names as the distribution channel for the malicious bundle AllMyBasic.msi — among six Romulus servers. Huntress, which reported the flaw through Jose Oregon, had already documented similar abuse of Canon- and Stardock-signed programs in late September.

The detail that should alarm you: the attackers spread a Siemens-signed program onto machines that never had Siemens software installed. The presence of SiemensSoftwareCenter.exe in startup apps or the Task Scheduler is therefore a compromise signal, not evidence of normality.

What a signature no longer protects

The lesson extends beyond Siemens. Code signing guarantees a binary’s integrity and origin — but it says nothing about the neighbouring files it loads. DLL side-loading exploits exactly that blind spot: the program is signed, but the DLL it looks up in its own folder is not. It is the same mechanism as the DOUBLECUP campaign and the abuse of Canon- and Stardock-signed programs: a signature is a trust token the attacker rents, not a defence they defeat.

The practical consequence for detection: do not hunt the binary — it is genuine — but the folder and the behaviour. Siemens explicitly recommends “detect on folder and behaviour, not on the Siemens file fingerprint.” Look for SiemensSoftwareCenter.exe running from AppData\Local\Programs and launched by msiexec, and for unexpected DLLs next to Software Center executables outside the default install folder.

The response: auto-patch, indicators, behavioural hunting

The fix comes down to one action. Siemens states that version 4.0.9.8 installs automatically on next startup of the application. Still, check machines where Software Center rarely runs: an application that never starts never updates. The fixed version is also downloadable from the official site.

The indicators of compromise published on October 19 should be blocked on firewalls, proxies and DNS resolvers, and searched for in logs:

• IP 96.62.218[.]59 — payload hosting / command and control (active);
• domain wizardexpensive[.]com — payload hosting / C2 (active);
• IP 2.27.248[.]127 — distribution channel for the AllMyBasic.msi bundle (inactive).

On a hit, Siemens advises: isolate the PC, stop the process first, then remove the startup entry and scheduled task, and reset passwords. Finally, train your users: a real “I am not a robot” check never asks anyone to paste a command into Win+R, the Run box or PowerShell.

Why now: signed-binary abuse is going mainstream

CVE-2026-110936 is not an isolated case: it sits inside a trend that Google Threat Intelligence Group counts at 141 exploited vulnerabilities between January and August 2026, against 127 for all of 2025. The abuse of signed programs — Canon, Stardock, now Siemens — follows the same logic: borrow a legitimate vendor’s reputation to push a payload through. Huntress summed up the conclusion in late September: “it’s highly likely other signed applications are being abused the same way.”

So the answer is not a one-off patch but a change of assumption. The trust model built on code signing must be complemented by behavioural hunting: who launches what, from which folder, with which neighbouring files. That is what Siemens recommends, and what detection teams must industrialise — an EDR configured to watch for DLL side-loading, not just signatures. For US federal agencies, BOD 26-04 sets the deadline at 3 days for exposed assets and 14 days for the rest, counted from the October 20 KEV entry.

One more reason to care: because the signed installer is spread outside official channels, a machine can be affected even if your organisation never deployed Siemens software. OT integrators and engineering suppliers run it without listing it anywhere, so third-party risk teams should fold this CVE into their supplier questionnaires today. The hunting rule is portable: on any Windows endpoint, a legitimately signed vendor binary running from an unusual folder next to unsigned DLLs is worth an incident ticket.

Verdict

If your fleet runs Siemens software, force version 4.0.9.8 now — the auto-update does not cover machines where Software Center never launches — and deploy the three indicators in your detection stack before November 3. If you onboard or audit OT suppliers, ask them today whether they run Software Center and whether they have hunted the indicators: the flaw is exploited in ClickFix campaigns that target machines with no Siemens software installed, so your exposure is not limited to engineering workstations. The real lesson of CVE-2026-110936 is that code signing is no longer enough — you must now watch what a signed binary loads, not just what it is.

References

• Siemens ProductCERT — SSA-580366, DLL Sideloading Vulnerability in Siemens Software Center (October 15, 2026, V1.2 of October 19)
• Siemens ProductCERT — Active Exploitation of CVE-2026-110936 in Siemens Software Center (October 19, 2026)
• CISA — CISA Adds Six Known Exploited Vulnerabilities to Catalog (October 20, 2026)
• Forescout Vedere Labs — ROMULUS: Analysis of a New Multi-Payload ClickFix Delivery Platform (October 15, 2026)
• Huntress — Attackers Abuse ChatGPT Custom GPTs to Deliver RAT via ClickFix (September 28, 2026)