A Trusted, Signed Application Became the Attack Vector
Siemens has confirmed that threat actors actively exploited a vulnerability in its Software Center application, tracked as CVE-2026-110936 with a CVSS v4 score of 8.4. The flaw affects all versions before 4.0.9.8 and stems from DLL side-loading: a validly signed copy of Software Center will load attacker-supplied, malicious DLLs placed in its own folder at startup, rather than only the legitimate libraries Siemens intended. That mechanism is what makes this disclosure notable, the executable itself is genuinely Siemens-signed, which is exactly the property most endpoint defenses use to decide something is safe to run.
Siemens was explicit that this is not a breach of its own systems. The company stated that no Siemens system, product or update channel was breached to its knowledge, and the advisory frames this as abuse of a legitimate, signed binary rather than a compromised supply chain. That distinction matters operationally: there is no tampered Siemens download to hunt for, instead the risk is that any machine already running an outdated Software Center is sitting with a side-loading door open to whatever a local attacker, or a successfully lured user, places next to it.
How the Side-Loading Mechanic Actually Works
DLL side-loading exploits a basic behavior in how Windows applications locate the libraries they depend on. If an application loads DLLs by name rather than by a fully verified path, and an attacker can place a malicious DLL with that same name in a folder the application searches first, the legitimate, signed executable will load and execute the attacker's code without any warning. The user or endpoint tool sees only the trusted, signed Software Center process running, while the actual malicious logic executes inside it.
This is precisely why side-loading bugs are prized by capable attackers over more obvious malware drops. A security team that allowlists applications by code signature, a common and reasonable control, will not flag this activity because the process that ends up running malicious code is the real, Siemens-signed Software Center. Detecting this class of attack requires looking at what a signed process actually loads and does at runtime, not just whether its own binary carries a valid signature.
ClickFix Lures Did the Delivery Work
Siemens linked the campaign exploiting this flaw to Romulus, a multi-platform delivery toolkit built around ClickFix-style social engineering. ClickFix attacks typically present a user with fake instructions, often disguised as a verification step or error fix, that trick them into running a command or installer that plants the attacker's payload themselves. In this case, that payload included the malicious DLL positioned to be side-loaded the next time the genuine, signed Software Center executable ran.
The choice of lure matters because it shifts the burden of compromise onto user behavior rather than a technical breach of any system. No firewall rule or patched server stops a user who is convinced to run a malicious script by a convincing fake prompt. That makes user-facing ClickFix awareness training, and browser or endpoint controls that block the specific command-execution patterns ClickFix relies on, a more relevant defense here than traditional network perimeter controls.
Romulus Is a Repeat Offender, Not a One-Off Tool
Siemens is not the only vendor whose signed software has been dragged into a Romulus-linked campaign. Security firm Forescout has separately tied the same Romulus delivery platform to LegionLoader malware and to a trojanized installer impersonating Stardock, and the broader campaign has also used Canon-signed binaries as cover. That pattern, legitimate vendor signatures from different companies repeatedly recruited into the same delivery infrastructure, indicates an attacker group systematically hunting for side-loadable, trusted executables across the software ecosystem rather than targeting Siemens specifically.
For a defender, the useful takeaway is that Romulus as an infrastructure is now a known quantity worth tracking independent of which vendor's binary it is abusing this week. Threat intelligence teams and MSSPs that build detections around Romulus's command-and-control and delivery patterns gain protection against the next signed application it recruits, not just this one, which is a better use of limited detection-engineering time than chasing each vendor advisory individually.
The Fix Is Automatic, but Verification Still Matters
Siemens disclosed the issue through advisory SSA-580366 on October 15, 2026, and updated it two days later to confirm the fix. Version 4.0.9.8 of Software Center applies automatically the next time an affected installation launches, which lowers the operational burden compared to a flaw requiring a scheduled patch window. For most organizations running Siemens Software Center, the practical fix path is simply ensuring the application is actually launched so the update-on-launch mechanism can run.
That automatic-update convenience should not be mistaken for a reason to skip verification. Any security team with Siemens Software Center in its environment should confirm, rather than assume, that instances have actually reached 4.0.9.8, particularly on machines that run infrequently or sit in segmented industrial network zones where automatic update traffic may be restricted. An unpatched instance sitting idle is exactly the kind of asset a DLL side-loading attack is built to find.
What This Means for Your Own Signed-Software Trust Model
This incident is a concrete argument for revisiting any security control that treats a valid code signature as sufficient proof of safety. Signature-based allowlisting is still a useful first filter, but this campaign shows that attackers have a reliable technique, DLL side-loading paired with ClickFix delivery, for turning a genuinely trusted binary into a malware launcher without ever forging a signature. Any environment with significant exposure to vendor-signed desktop applications, which in practice means nearly every enterprise, should assume this technique will recur against some other vendor next.
The concrete roadmap items are patch verification discipline for applications that update silently, runtime behavioral monitoring on signed processes rather than reliance on signature checks alone, and user training specifically against ClickFix-style prompts, since the delivery mechanism here depended entirely on a human being convinced to run something. Building those three controls now costs far less than responding to the next vendor advisory that names your organization's software stack specifically.
