SURIQ
CISA added CVE-2026-110936 to its Known Exploited Vulnerabilities catalog on October 20, 2026, and Siemens confirmed the day before that attackers are already using it in the wild. The flaw is a dynamic-link library (DLL) search-path problem in Siemens Software Center, the Windows client that installs and updates Siemens engineering tools. On paper it reads like a low-urgency local bug. How it is being exploited is the part that should change how you hunt.
The gap the advisories skip: the attackers are not logging in as a privileged user to abuse this. They ship a legitimate, digitally signed copy of the Siemens client next to a malicious DLL, and let Windows load the attacker's code under the trusted binary's name. A hash or signature allowlist sees a valid Siemens executable and waves it through. The malicious part never touches the signed file.
What CVE-2026-110936 actually is
Siemens classifies the bug as CWE-427, an uncontrolled search path element, in Siemens Software Center. Every version before V4.0.9.8 is affected, and V4.0.9.8 fixes it. Siemens scores it 6.7 on CVSS version 3.1 and 8.4 on CVSS version 4.0. The application looks for DLLs in a directory it does not restrict, so a DLL planted in that search path runs with the privileges of the Software Center process.
The CVSS version 3.1 vector describes a local attacker who already holds high privileges, which is why that base score looks modest. The model undersells the real threat. In the observed attacks the privilege requirement is sidestepped by social engineering: a user is tricked into running an installer, and the installer drops both the signed Siemens binary and the rogue DLL into a writable folder. CISA does not add a product to KEV without reliable evidence of active exploitation, and this one now carries a federal patch deadline of November 3, 2026.
How the ClickFix campaign uses it
Siemens attributed the activity to a delivery operation it tracks as Romulus, which it describes as a multi-platform ClickFix operation. ClickFix is a lure that convinces a user to run something themselves, so the malicious action begins from a user-initiated step instead of a remote exploit. According to analysis by SOC Prime, the chain runs msiexec, the Windows installer service, against a package named AllMyBasic.msi, which then starts the real SiemensSoftwareCenter.exe. That signed binary loads a malicious archive.dll sitting beside it, and the attacker's code executes inside a process Windows and most tools consider trustworthy.
That is DLL side-loading, mapped to MITRE ATT&CK technique T1574.002, paired with user-executed delivery (T1204). We have watched the same signed-binary trick land in unrelated campaigns this year, from a fake Notepad plugin that sideloaded a loader to Lazarus abusing trusted Windows components. The target changes; the evasion does not.
Network indicators (published with the campaign): wizardexpensive[.]com 96.62.218[.]59 2.27.248[.]127 Files seen beside the signed binary: AllMyBasic.msi delivery package, run via msiexec.exe archive.dll the sideloaded malicious library activate.bak artifact next to SiemensSoftwareCenter.exe statinfosta.DB artifact next to SiemensSoftwareCenter.exe %LOCALAPPDATA%\FTSuite\ftc.uml Hunt on behavior, not hash: SiemensSoftwareCenter.exe running from %LOCALAPPDATA%\Programs SiemensSoftwareCenter.exe with parent process msiexec.exe any unexpected .dll written next to a signed vendor binary outbound traffic from that process to the addresses above ATT&CK: T1574.002 DLL side-loading, T1204 user execution, T1566 phishing
Why your allowlist misses it, and what to watch instead
The lesson reaches past Siemens. Code signing proves who built a file, not what that file does once another library loads beside it. Monitoring the hash of SiemensSoftwareCenter.exe is useless here, because the exploited file is the genuine, correctly signed one. The signal lives in context: where the trusted binary runs from, what launched it, and which libraries load next to it. It is the same blind spot a backdoor dressed up as a security tool relies on, a name check that trusts the label over the behavior.
Three questions matter for a defender tonight. Is a signed vendor binary executing out of a user-writable path like AppData instead of its real install directory? Was it spawned by msiexec rather than a normal update flow? Did an unsigned or unexpected DLL appear in the same folder just before it ran? Any one of those deserves an alert. Together they are this campaign.
What to do now
Patch first. Update Siemens Software Center to V4.0.9.8 or later. Siemens states that existing installations auto-update on next startup, so confirm the client can actually start and reach the update service rather than assuming it already happened. The federal deadline is November 3, but the exploitation is current, so treat it as this week's work whether or not you answer to CISA.
Then hunt. Patching closes the search-path hole; it does not tell you whether the bundle already ran. Sweep your Windows fleet for the file and network indicators above, check process lineage for the signed binary running from AppData under msiexec, and flag any host that reached the listed infrastructure. If you run Siemens engineering software anywhere, those endpoints are the first ones to open.