Siemens Software Center CVE-2026-110936: exploited DLL side-loading

The attacks on CVE-2026-110936 did not need Siemens Software Center to be installed. Attackers took a genuine copy, signed by Siemens, put their own DLL files next to it and delivered the bundle through ClickFix, a fake "I am not a robot" check that asks the visitor to paste a command. The signed program started, loaded the attackers' DLLs from its own folder and ran their code.

Siemens published advisory SSA-580366 on 15 October 2026 and added the fixed version, 4.0.9.8, on 17 October. The advisory credits Jose Oregon of Huntress Labs with reporting the flaw. On 19 October it confirmed active exploitation, published indicators and tied the activity to the "Romulus multi-platform ClickFix campaign". CISA added the CVE to its Known Exploited Vulnerabilities catalog on 20 October, with a 3 November deadline for federal agencies.

Who is affected

Siemens Software Center is the tool Siemens customers use to download, install, activate and update purchased Siemens software. The advisory lists one product:

The flaw concerns Windows DLLs. Siemens also ships Linux installers, and the advisory does not say whether those builds are affected.

Two groups are exposed. Anyone running an old copy has the bug on disk. And any Windows PC whose user can be talked into pasting a ClickFix command can receive a vulnerable copy from the attacker: the first warning sign Siemens lists is "Siemens Software Center" in the start-up apps or Task Scheduler of a PC that never had it installed.

How the side-loading works

When a Windows program loads a DLL by name without a full path, Windows normally looks in the program's own folder before the system folder. Microsoft warns that an attacker who controls a searched folder can plant a malicious copy there.

Siemens classes the flaw as CWE-427, Uncontrolled Search Path Element. Version 3.5.8.7, it says, "loaded helper files from its own folder without checking them". Whoever controls that folder runs code inside a Siemens-signed process. Siemens stresses that its program was not modified; the malicious code was in the DLLs the attackers supplied. It does not say which DLLs the program expects or how 4.0.9.8 changes its loading.

Siemens's account, read alongside Forescout's analysis of the ROMULUS platform, gives this outline:

1. Lure. A web page asks the visitor to paste a command into Win+R, the Run box or PowerShell.
2. Installer. In Forescout's analysis of ROMULUS, the command fetches a PowerShell script that silently installs an MSI package with msiexec. Siemens names the installer in this campaign, AllMyBasic.msi, distributed from 2.27.248[.]127 outside Siemens's channels.
3. Side-load. The genuine SiemensSoftwareCenter.exe runs from AppData\Local\Programs, where Siemens says the malware creates a folder called SM Software Provisioning Service, and loads the attackers' DLLs. Siemens names one, archive.dll.
4. Persistence and control. Siemens's clean-up steps name a start-up entry and a scheduled task, and it lists 96.62.218[.]59 and wizardexpensive[.]com as payload hosting and command and control.

The scores reflect the bug, not the campaign. Siemens rates it 6.7 in CVSS 3.1 and 8.4 in CVSS 4.0, both assuming a local attacker who already holds high privileges. In these attacks the victim's own pasted command does the placing. CISA's SSVC assessment records exploitation as active, not automatable, with total technical impact.

Is it being exploited?

Yes. Siemens says it "has validated that there is an active exploitation" of the flaw, and CISA added it to KEV on 20 October. The catalog lists ransomware use as unknown.

• Attribution. Siemens names the Romulus multi-platform ClickFix campaign. On 15 October Forescout's Vedere Labs described ROMULUS as a reusable ClickFix delivery panel and listed six servers running it, among them 2.27.248[.]127, the address Siemens gives for AllMyBasic.msi. Forescout's report does not mention Siemens and says the operator is unknown.
• Rotating carriers. Huntress has reported since 28 September on ClickFix chains that side-loaded through a Canon-signed application and later Stardock's DeElevate64.exe; Forescout found a ROMULUS route using the Stardock program. Siemens Software Center fits that pattern of swapping signed hosts, though neither report names Siemens.
• Siemens's own systems. "No Siemens system, product or update channel was breached to our knowledge."

What is not public: the final payload and the number of PCs affected. Some coverage calls the payload a remote access trojan, which we could not confirm against a primary source. A figure of 40 incidents seen in some reports comes from Huntress's earlier Canon and Stardock campaign, not this one.

Check your exposure

Two questions for each Windows PC: is there a Siemens Software Center older than 4.0.9.8, and is there one nobody installed?

# Walks the whole system drive; run elevated to include every user profile
Get-ChildItem -Path C:\ -Filter SiemensSoftwareCenter.exe -Recurse -File -ErrorAction SilentlyContinue |
  Select-Object FullName, @{ n = 'Version'; e = { $_.VersionInfo.ProductVersion } }, LastWriteTime

Any copy below 4.0.9.8 needs the update. A copy under a user's AppData\Local\Programs that your team did not deploy needs a closer look whatever its version. At fleet scale, an endpoint or software inventory query for the same file name answers both questions.

Fix it

1. Start Siemens Software Center on every PC that has it. Siemens says existing installations update to 4.0.9.8 automatically on the next start.
2. Where that fails, download the current installer from Siemens's Software Center page, which lists a SHA-256 checksum for each installer. Siemens asks customers to use only official sources.
3. Run the inventory check again and confirm every copy reports 4.0.9.8 or later.
4. Block 96.62.218[.]59, wizardexpensive[.]com and 2.27.248[.]127 on firewalls, proxies and DNS resolvers, as Siemens advises.

Siemens's advice to users is short: never paste a command from a web page into Win+R, the Run box or PowerShell, because a real human check never asks for that.

Detect attempts and compromise

Siemens has published these signals:

• Start-up entries. "Siemens Software Center" in start-up apps or Task Scheduler on a PC that never had it installed.
• Folders. SM Software Provisioning Service inside AppData\Local\Programs, and FTSuite containing ftc.uml inside AppData\Local.
• Files. activate.bak or statinfosta.DB next to SiemensSoftwareCenter.exe, and unexpected DLLs next to any copy outside its normal installation folder.
• Process. SiemensSoftwareCenter.exe running from AppData\Local\Programs, started by msiexec.
• Network. Connections to 96.62.218[.]59 or wizardexpensive[.]com, active when Siemens published, and past downloads from 2.27.248[.]127, now offline.

# Folders Siemens says the malware creates
Test-Path "$env:LOCALAPPDATA\Programs\SM Software Provisioning Service"
Test-Path "$env:LOCALAPPDATA\FTSuite\ftc.uml"
 
# Marker files Siemens lists next to the planted executable
Get-ChildItem "$env:LOCALAPPDATA" -Recurse -File -Include activate.bak, statinfosta.DB -ErrorAction SilentlyContinue |
  Select-Object FullName, LastWriteTime
 
# Start-up entries and scheduled tasks that launch it
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run'
Get-ScheduledTask | Where-Object { $_.Actions.Execute -like '*SiemensSoftwareCenter*' }
 
# Open connections to the command-and-control address
Get-NetTCPConnection -RemoteAddress 96.62.218.59 -ErrorAction SilentlyContinue

AllMyBasic.msi  f4d7c5321bb0d1bda439304a753bcf9b467b98ca53c7e9493b9c2c3451092e4a
archive.dll     3fdcc7d7d049a89711fb31fb236940a1c5a09d899143ffd20c3c41fb1f2cf491

Siemens warns against detecting on the Siemens executable's hash, because the file is genuine; detect on the folder and the behaviour instead. If anything fires, Siemens says to isolate the PC, stop the process first, then remove the start-up entry and the task, and reset passwords.

Signed is not the same as safe

Siemens says the attackers chose its program "because it is signed and trusted". A signature proves who built a file, not what it loads, and the same campaign style has already moved through Canon and Stardock binaries. Hunting on where a signed program runs from and who started it is more likely to catch the next swap than a hash or vendor name. Confirm the fix with evidence, not a version string; how a retest verifies a fix explains Rokkhe's approach for findings it has reproduced.