Siemens disclosed Monday that attackers exploited a DLL sideloading flaw in Siemens Software Center as part of a malware campaign, and the company had patched the issue two days after its October 15 advisory.
The vulnerability, tracked as CVE-2026-110936, carries a CVSS v4 score of 8.4. It exists because Software Center does not properly restrict where it searches for DLL files. An authenticated local attacker can plant a malicious DLL in one of those folders and get their code executed with the same privileges as the application.
Siemens Software Center handles the download, installation, activation, and updating of software customers have purchased, and it can start free trials. That reach makes it an attractive carrier for malware that wants to ride on a trusted name. The application is common in industrial and engineering environments where Siemens products are standard, which widens the pool of potential victims considerably.
The nut graf: defenders have a signed, legitimate Siemens binary being abused to side-load malicious code, which means file-hash blocklists will not catch it. Siemens told customers to focus on suspicious behavior and the folders tied to the malware instead of hashes.
What CVE-2026-110936 Actually Does
The flaw is a classic DLL sideloading weakness. Software Center version 3.5.8.7, the newest release at the time, did not validate helper files before loading them. Attackers paired a legitimate copy of the Siemens program, which carried a valid digital signature, with malicious DLL files they supplied themselves. When the program started, it loaded the attacker-provided files from its own folder.
Siemens said its software was not tampered with, and the malicious package was not spread through Siemens distribution channels. "No Siemens system, product or update channel was breached to our knowledge," the company said. That distinction matters for customers deciding whether to trust an already-installed copy.
The company updated the advisory on October 17 to say version 4.0.9.8 resolves the issue. Users who already have the application installed will receive the fix automatically the next time they launch it. The advisory did not mention in-the-wild exploitation until Monday, when Siemens added a link to a new blog post describing the attacks.
Huntress researcher Jose Oregon reported the vulnerability to Siemens.
ClickFix and the Romulus Platform
Siemens linked the attacks to Romulus, a multi-platform ClickFix campaign. ClickFix attacks rely on fake prompts, such as bogus CAPTCHA checks, that instruct users to paste and execute malicious commands on their own devices. The social engineering happens in the browser, and the payload lands on the endpoint.
Last week, Forescout published research on Romulus, a ClickFix delivery platform that can serve several different malware payloads. The security firm found the platform running on several servers, including the one Siemens identified as the distribution server for the malicious bundle containing its software.
Forescout saw the platform deliver LegionLoader malware, as well as a trojanized installer that leveraged a legitimate Stardock application for DLL side-loading. The researchers could not determine who runs Romulus. It could be a private tool, a service sold to cybercriminals, an affiliate program, or software copied by different threat actors.
Huntress described the same Stardock-based package in a late-September report on a campaign that used rogue ChatGPT Custom GPTs to lure users to ClickFix pages. In those attacks, signed programs from Canon and later Stardock were abused to side-load malicious code that ultimately deployed a remote access trojan.
Huntress responded to at least 40 incidents linked to the campaign, and said it believes signed programs from other vendors are probably being misused as well.
Siemens Software Center is not mentioned in the Huntress or Forescout reports. The overlapping infrastructure and the similar side-loading approach suggest the Siemens program may have been added to the same toolkit.
Detection and Response
Because the Siemens file used in the attacks is legitimate, Siemens recommends that defenders focus on suspicious behavior and the folders associated with the malware instead of relying on file hashes. That is a harder ask for understaffed security teams, but it is the only reliable approach when the carrier binary is signed.
Siemens is sharing threat intelligence with authorities and EDR providers. Its blog post lists indicators of compromise, as well as signs that a computer may have been infected.
I think the more worrying detail is the lag between patch and disclosure. Siemens patched on October 17 but did not flag in-the-wild exploitation until Monday. Customers who read the original advisory may have treated the flaw as theoretical and deprioritized it. That gap is the kind of thing that turns a manageable DLL sideloading bug into an active intrusion.
What Defenders Should Do Now
First, confirm Software Center is updated to version 4.0.9.8 or later. The auto-update on next launch covers most users, but air-gapped or rarely used installs may be sitting on older versions. Second, hunt for the IoCs Siemens published, especially unexpected DLLs in the Software Center directory. Third, block the Romulus distribution infrastructure where your tooling permits, since Forescout mapped several of those servers.
For broader context on patch discipline, see our desk coverage of recent critical flaws, and the SecurityWeek report on this incident.
Open Questions
Who runs Romulus remains unknown. The platform could be a private tool, a service sold to cybercriminals, an affiliate program, or software copied by different threat actors. That ambiguity means the same delivery infrastructure may resurface under a different name.
It is also not clear how many organizations were hit through the Siemens binary specifically. Huntress logged at least 40 incidents across the wider campaign, but Siemens Software Center is not named in those reports. The overlap in infrastructure suggests the Siemens program was added to the toolkit, but the scale of that particular vector is unverified.
The next test for defenders is whether EDR vendors can build behavior-based detections fast enough to keep pace with a campaign that swaps carriers but keeps the same ClickFix delivery and DLL side-loading playbook. Siemens sharing IoCs with EDR providers should help, but the campaign's modular design means the next signed binary is probably already lined up.