Vulnerabilities

Siemens Software Center, the Windows application Siemens customers use to download, install, activate and update purchased Siemens software, has a DLL side-loading flaw tracked as CVE-2026-110936. Siemens rates it CVSS v4.0 8.4 (6.7 under CVSS v3.1) in advisory SSA-580366, credits Jose Oregon of Huntress Labs with reporting it, and fixed it in version 4.0.9.8. Attackers are already using it: they ship a genuine, validly signed copy of the program alongside their own DLLs, so the code that runs carries the trust of a Siemens signature.

Siemens published the advisory on October 15, added the fix on October 17 and warned of active exploitation on October 19, tying it to the Romulus ClickFix campaign. CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog on October 20, with a November 3 deadline for US federal agencies. The exposure is wider than Siemens customers: the attackers bring their own copy, so any Windows PC whose user can be talked into pasting a command is in scope, whether or not it ever had Siemens software installed.

How it works

When a Windows program asks for a DLL by name rather than by full path, the loader searches a list of folders, and the program's own directory comes first. A program that expects a helper library to be installed beside it will therefore load whatever file of that name is sitting there. Siemens describes the bug as CWE-427, an uncontrolled search path element: the affected versions load helper DLLs from the application folder without checking that they are Siemens files. Siemens says version 3.5.8.7, the latest release when the attacks were seen, behaved this way.

The attacker gets two things from that. Their code runs inside a process whose executable is signed by Siemens and has not been modified, so application allowlists, reputation services and analysts who check the parent binary see nothing wrong. And because the attacker controls the whole folder, they do not need a vulnerable copy to already exist on the target. They install one.

The CVSS vector reflects the textbook case: a local attacker with high privileges planting a DLL (AV:L, PR:H). In this campaign the "local attacker" is the victim, who runs the installer after following ClickFix instructions. So the score understates real-world risk here: the user grants the privileges the vector assumes an attacker already holds.

What attackers are doing

Siemens attributes the activity to Romulus, a ClickFix campaign that targets several platforms. ClickFix pages show a fake verification check and tell the visitor to paste a command into the Run box (Win+R) or PowerShell; Siemens notes that a real CAPTCHA never asks for this. Our earlier posts on paste warnings in Chrome and the Custom GPT lure cover the lure itself.

The Siemens chain, as Siemens describes it:

• msiexec.exe runs an installer named AllMyBasic.msi, distributed from 2.27.248[.]127 and never from a Siemens channel.
• The package drops SiemensSoftwareCenter.exe into a folder under AppData\Local\Programs, next to the attacker's files.
• The signed program starts, loads the attacker DLL and gives it persistence through a startup entry or scheduled task.

Siemens lists archive.dll among the malicious files and states that "no Siemens system, product or update channel was breached to our knowledge."

Forescout's Vedere Labs had published research on ROMULUS, the delivery panel behind this activity, a few days earlier. Infosecurity Magazine dates it October 14; Forescout's own page shows October 15. Forescout found the panel on six IP addresses, one of them 2.27.248.127, the same host Siemens names as the source of AllMyBasic.msi. Each panel serves a PowerShell staging script and then either a trojanized MSI or an encrypted archive. One MSI route abused a signed Stardock tool in exactly the same way, with a patched DeElevator64.dll beside DeElevate64.exe. Another route ended in LegionLoader, a loader active since 2019 that reads Chrome's Local State key to collect browser data.

Be careful with one link in the coverage. Some reports present LegionLoader as the payload of the Siemens chain. Forescout ties LegionLoader to a separate ROMULUS route, and Siemens does not name the final malware in its own write-up. What is confirmed is shared infrastructure, not a shared payload. Forescout also does not know who runs ROMULUS: it may be a private panel, a commercial delivery service or software copied between operators.

What to do

1. Update and verify

Move every install to Siemens Software Center 4.0.9.8 or later. Siemens says existing installs update themselves on next start, but a copy that is rarely opened stays on the old build until then, so check the installed version through your software inventory rather than trusting the auto-update. Siemens lists no workaround in SSA-580366.

The affected range needs a note. The advisory says all versions before 4.0.9.8 are affected. Siemens' exploitation post and the press name 3.5.8.7, which was the version abused. Both are true; treat anything below 4.0.9.8 as vulnerable. An early OpenCVE record showed no fix available, which predates the October 17 update.

2. Block the infrastructure

Add Siemens' active indicators to firewall, proxy and DNS block lists: 96.62.218[.]59 and wizardexpensive[.]com, both used for payload hosting and command and control. The distribution host 2.27.248[.]127 is inactive, but search past proxy and firewall logs for it.

3. Hunt for the chain

Hashes of the Siemens binary will not help, because it is the real file. Look for behaviour and location instead:

• Process creation (Sysmon event ID 1 or Security event 4688) where SiemensSoftwareCenter.exe has msiexec.exe as its parent and an image path under AppData\Local\Programs.
• A folder named SM Software Provisioning Service under AppData\Local\Programs.
• activate.bak or statinfosta.DB beside SiemensSoftwareCenter.exe, and an FTSuite folder holding ftc.uml under AppData\Local.
• A Siemens Software Center entry in startup apps or Task Scheduler on a PC where nobody installed it.
• Module loads (Sysmon event ID 7) of DLLs not signed by Siemens into SiemensSoftwareCenter.exe from any folder other than the default install path, and the AllMyBasic.msi and archive.dll SHA-256 hashes from Siemens' post.

4. Clean up a hit

Siemens' order is: isolate the host, stop the process first, then remove the startup entry and the scheduled task, then reset the user's passwords. Because ROMULUS also delivers browser data stealers, sign the user out of their web sessions and revoke tokens for the cloud services they use, not only the Windows password.

The wider lesson

This is the same pattern as the Canon and Stardock binaries in earlier ClickFix waves: a trusted vendor's executable used as a host for someone else's code. Allowlisting by publisher would have let every one of them run. Rules that tie a signed binary to its expected install path and parent process catch the whole family whichever vendor's file comes next, and so does alerting on msiexec started by a PowerShell process with a URL on its command line.

Our security operations team writes and tunes detections like the process-lineage rules above, and our safeguarding and hardening work sets up application control that checks path and parent, not just the signature. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Siemens SSA-580366, Siemens ProductCERT exploitation post, CISA KEV catalog, Forescout Vedere Labs, Help Net Security, SecurityWeek, Infosecurity Magazine, Daily Security Review, Safeguard.