- Siemens says attackers are exploiting CVE-2026-110936 by placing malicious files beside a genuine, signed copy of Software Center. Version 4.0.9.8 fixes the flaw.
- The Siemens file is unaltered, so checks based on file fingerprints miss it. Siemens advises defenders to detect on folders and behaviour instead.
- Confirm Software Center is at 4.0.9.8 or later, block the indicators Siemens lists, and search logs for the folders and files it names.
The file was real. The folder was not.
Signatures are widely treated as a sign of trustworthy software. Siemens ProductCERT now reports that attackers are turning that assumption against defenders.
The attackers left the signed Siemens program exactly as Siemens made it. They simply set their own files beside it.
The lesson here is plain. A signature vouches for one file. It says nothing about the folder that file runs from, or the neighbours it loads.
What Siemens says happened
On 19 October, Siemens ProductCERT confirmed that attackers are exploiting CVE-2026-110936 in Siemens Software Center. The flaw lets the program load a malicious helper file, called a DLL, from its own folder.
SecurityWeek describes Software Center as the tool customers use to manage purchased Siemens products, from first download to later updates. It can also start free trials.
Siemens published advisory SSA-580366 on 15 October. Version 4.0.9.8 contains the fix. Installed copies update themselves the next time they are opened.
SecurityWeek reports a CVSS v4 score of 8.4 for the flaw. It says Huntress researcher Jose Oregon is credited with reporting it to Siemens.
Siemens says that, as far as it knows, none of its systems, products or update channels were breached. According to Siemens, the attackers spread the bundle through channels outside its control.
How the trick works
Many Windows programs depend on helper files. If a program loads them from a folder an attacker controls, and does not check them, it runs whatever code they hold.
Siemens says the attackers wanted a carrier that was both signed and trusted. Version 3.5.8.7 fit, because it pulled in helper files from its own folder and never verified them. At the time, it was the latest release.
The attackers built a package holding the real program and their own DLLs. When the program started, it loaded the attacker's files.
Siemens stresses that its program was not modified. The malicious code sits only in the supplied DLLs. The signature on the main program still passes, because that file is what Siemens shipped.
The human step: ClickFix
Siemens ties the attacks to Romulus, which it calls a multi-platform ClickFix campaign. SecurityWeek explains the method. Fake prompts, such as bogus CAPTCHA checks, push users to paste and run malicious commands themselves.
Forescout published research last week on Romulus. It is a platform that can deliver several kinds of malware. Forescout traced it to several servers. Siemens says one of them hosted the malicious Siemens bundle.
Forescout could not tell who runs Romulus.
Huntress had reported a related package, built on an app from Stardock, in late September. That campaign baited people with fake ChatGPT Custom GPTs and sent them to ClickFix pages. Signed Canon programs, and later Stardock ones, were used to load malicious code.
Huntress handled at least 40 related incidents. It suspects signed programs from other vendors are being abused too.
Neither the Huntress report nor the Forescout report names Siemens Software Center. SecurityWeek points to shared servers and a similar method. It suggests the Siemens program joined the same toolkit. That is SecurityWeek's inference.
Why this is hard to catch
Tools that block known-bad file fingerprints see nothing wrong here. The Siemens file is genuine. Siemens tells defenders to detect on folders and behaviour instead.
This shows a gap in a common rule. A policy that allows software on the strength of its signature alone would likely let this package through. The control has to look at where a program runs and what it loads.
The sources do not say how many organisations were affected. Treat this as one reported campaign. It does not measure how common the technique is.
What to ask your team
First, is Siemens Software Center at version 4.0.9.8 or later wherever it is installed? Starting the application installs the update.
Second, do your monitoring tools raise an alert when the Software Center executable runs from a user's AppData\Local\Programs folder after being launched by msiexec, the Windows installer tool? Siemens lists this as a sign of infection.
Third, have you searched for the other signs Siemens names? One is a folder called SM Software Provisioning Service. Another is files named activate.bak or statinfosta.DB beside the executable. A third is a folder called FTSuite holding ftc.uml. A "Siemens Software Center" start-up entry on a PC that never had it is also a sign.
Fourth, are the network indicators blocked? Siemens's block list covers two IP addresses, 96.62.218[.]59 and 2.27.248[.]127, plus one domain, wizardexpensive[.]com. Some were still reachable when Siemens published. Machines that downloaded from the now-offline channel may still be infected.
If a PC is affected, Siemens advises isolating it and stopping the process first. Only after that should the team delete the start-up item and scheduled task the malware created, and change the account passwords.
Finally, train staff on the lure itself. Siemens says a real "I am not a robot" check never asks you to paste a command into the Run box or PowerShell.
A signature tells you who made a file. It does not tell you who put it there.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Siemens ProductCERT.
