CVE-2026-110936 (CVSS 8.4): ClickFix Campaign Hijacks Siemens Software Center — Patch OT Endpoints Now

A trusted industrial software tool has become a weapon. On 19 October 2026, Siemens confirmed that CVE-2026-110936 — a DLL sideloading flaw in its Software Center application — is being actively exploited in an ongoing ClickFix malware campaign. For the hundreds of thousands of engineers, plant operators, and IT administrators who rely on Siemens Software Center to download and update automation components, the message is urgent: check your version right now.

What makes this incident particularly worrying is the attacker’s method. They did not crack Siemens’ servers or tamper with the installer package. Instead, they weaponised trust itself — distributing a legitimate, digitally-signed copy of the Siemens executable alongside attacker-controlled DLL files, tricking Windows into loading malicious code under the application’s own privileges. In environments where Siemens software carries implicit “approved by IT” status, that signature is a skeleton key.

What Is CVE-2026-110936 — and Why Does It Matter for OT/ICS Environments?

Siemens Software Center (SSC) is the single pane of glass for downloading, installing, licensing, and updating Siemens products — from SIMATIC WinCC and TIA Portal to STEP 7 and Automation Designer. In a typical Indian manufacturing or energy plant, SSC is installed on every engineer workstation and often on shared “update servers” that push software to OT networks.

The flaw, tracked as Siemens Security Advisory SSA-580366, is classified as CWE-427: Uncontrolled Search Path Element. When Windows launches the SSC executable, it searches a list of directories for required DLL files. Because the application does not pin the full path of each dependency, an attacker who places a maliciously-named DLL in a directory that appears earlier in the search path — such as the same folder as the executable, or a location a standard user can write to — can cause Windows to load their code instead of the legitimate library.

Critically, this exploit works without administrator rights, without a network connection, and without breaking Siemens’ code-signing certificate. The Siemens executable itself remains untouched and validly signed; only the adjacent DLL is attacker-controlled.

Attribute	Detail
CVE ID	CVE-2026-110936
Affected Product	Siemens Software Center < 4.0.9.8
CVSS v4.0 Score	8.4 (High)
CWE	CWE-427: Uncontrolled Search Path Element
Advisory	SSA-580366 (published 15 Oct 2026)
Exploitation Confirmed	19 October 2026
Campaign	Romulus ClickFix (RAT delivery)
Fix	Update to version 4.0.9.8 (auto-applies on next launch)
Researcher	Jose Oregon, Huntress Labs

The Romulus ClickFix Attack Chain: How It Works

ClickFix is an attacker technique that has surged in 2026. Rather than exploiting code, it exploits human psychology — presenting users with a fake “fix required” prompt that asks them to paste a PowerShell or terminal command, ostensibly to resolve a software error. In the Romulus variant linked to this campaign, the delivery method is more surgical:

1. Lure delivery: The victim receives a phishing email, a compromised site redirect, or a Telegram/WhatsApp message instructing them to download Siemens software from what appears to be a legitimate source. The downloaded archive contains the genuine, signed Siemens Software Center binary.
2. Malicious DLL placement: Alongside the genuine binary, the archive silently drops one or more attacker-crafted DLL files — named to match libraries SSC loads at startup — into the same directory or a writeable path the application searches.
3. DLL sideloading: When the user launches Siemens Software Center (a routine, trusted action), Windows resolves the DLL search path, finds the malicious DLL first, and loads it under the SSC process context. The Siemens application window opens normally — the user sees nothing amiss.
4. RAT execution: The malicious DLL spawns a Remote Access Trojan in the background. From this foothold, attackers can exfiltrate credentials, establish persistence, and pivot deeper — including into connected OT or SCADA networks.

The digital signature of the SSC executable remains valid throughout. Traditional antivirus tools and application control policies that whitelist by signature alone will not catch this. This is why behavioural detection, DLL load monitoring, and zero-trust application control are now essential layered defences.

The ICS/OT Risk: Why Indian Manufacturers Must Act Fast

India is Siemens’ fourth-largest global market. Siemens automation technology is embedded in steel plants in Odisha, textile mills in Tamil Nadu, pharmaceutical GMP lines in Himachal Pradesh, metro rail networks in Delhi and Hyderabad, and power distribution substations across the country. In most of these environments, engineer workstations sit at the IT/OT boundary — they connect to both corporate email (where phishing arrives) and to the PLC/DCS network (where damage is done).

An attacker who achieves RAT persistence on a Siemens Software Center host in a manufacturing plant could:

• Harvest credentials for TIA Portal, WinCC, or SCADA dashboards
• Silently modify PLC logic or historian configurations
• Stage ransomware against both IT and OT segments simultaneously
• Exfiltrate production data, IP, or safety parameters to a foreign adversary

This is not theoretical. As we reported last week on the Danfoss OT cyberattack, OT-targeting campaigns are escalating in both frequency and sophistication. The attack chain exploiting CVE-2026-110936 shows that adversaries no longer need to hack OT protocols — they can ride in on a trusted software update tool.

Technical Breakdown: DLL Sideloading in Depth

DLL sideloading exploits the Windows DLL search order (as documented in Microsoft’s documentation). By default, when an application calls LoadLibrary("example.dll") without specifying an absolute path, Windows searches:

1. The directory from which the application loaded
2. %SYSTEMROOT%\System32
3. %SYSTEMROOT%
4. The current working directory
5. Directories in the PATH environment variable

Because SSC does not use Safe DLL Search Mode or absolute path references for all dependencies, placing a malicious DLL in the application directory is sufficient to hijack execution. Modern mitigations like KnownDLLs registry keys and DLL redirection only protect a fixed set of system libraries — custom or product-specific DLLs are not covered.

Detection indicators to hunt for in your SIEM:

• Siemens Software Center process (SiemensSoftwareCenter.exe) spawning unexpected child processes (PowerShell, cmd, wscript)
• DLL loads from the SSC application directory that are not signed by Siemens AG
• Outbound connections from SiemensSoftwareCenter.exe to non-Siemens IP ranges or domains
• New scheduled tasks or registry run keys created shortly after SSC execution

What You Should Do Right Now — Sanjay Seth’s Defensive Playbook

This is an actively exploited, high-severity vulnerability confirmed less than 24 hours ago. Here is the prioritised action plan for Indian IT leaders and security practitioners:

Immediate (within the hour)

• Patch SSC to 4.0.9.8 — This is the primary fix. The update deploys automatically the next time a user launches Siemens Software Center. In managed environments, push this centrally via Siemens Automation License Manager, WSUS, or your endpoint management platform rather than waiting for each user to open the app organically.
• Block execution of older SSC versions — Use AppLocker or WDAC rules to prevent SiemensSoftwareCenter.exe from launching if its version is below 4.0.9.8.
• Block the Romulus IOCs — Obtain the indicator list from Siemens SSA-580366 and push them to your firewall, proxy, and EDR immediately.

Short-Term (within 24 hours)

• Hunt for compromise — Query your EDR and SIEM for the detection indicators listed above. Look back at least 14 days, covering the period between advisory publication (15 Oct) and the exploitation confirmation (19 Oct).
• Isolate engineer workstations with OT access — Temporarily quarantine any Siemens-managed endpoint that has both internet access and a live OT/SCADA connection until you confirm it is clean and patched.
• Enable DLL load auditing — Configure Windows Defender Application Control (WDAC) or Microsoft’s Process Mitigation options to alert on unsigned DLL loads in the SSC process.

Strategic (within the week)

• Review your software download policy — Ensure engineers download Siemens software only from the official support.industry.siemens.com portal, not from third-party mirrors or peer-shared archives.
• Apply zero-trust principles at the OT boundary — As detailed in our zero-trust campus architecture guide, engineer workstations should be micro-segmented from the OT network with FortiGate firewall policies enforcing least-privilege communication.
• Enable application control on FortiGate — Use FortiGate’s IPS and application control policies to detect and block lateral movement from compromised engineer hosts into OT VLANs.
• Train your team on ClickFix lures — Show your IT staff and engineers what a ClickFix prompt looks like. The social engineering component is as important to address as the technical patch.

As a zero-trust and FortiGate specialist, I have been advocating for strict micro-segmentation between IT and OT networks since long before incidents like this became commonplace. CVE-2026-110936 is a powerful reminder: the threat does not always arrive through the firewall — sometimes it walks in through the front door wearing a trusted badge.

Siemens’ Response and the Wider Supply-Chain Lesson

Siemens deserves credit for transparency here. Advisory SSA-580366 was published within days of researcher Jose Oregon’s disclosure via Huntress Labs. The auto-update mechanism in SSC 4.0.9.8 means patching is frictionless for users with internet-connected workstations. Siemens also confirmed its own infrastructure was not compromised — the attack exploits a client-side trust assumption, not a server-side weakness.

But the incident raises a question every enterprise must now ask: How many other signed, trusted vendor tools in your environment might have a similar DLL search order issue? Security researchers at Help Net Security and SecurityWeek note that ClickFix-style campaigns are increasingly targeting signed industrial and enterprise software precisely because the trust barrier is lower and detection is harder.

The Canadian Cyber Centre issued advisory AV26-1063 on 19 October urging all Canadian organisations using SSC to patch immediately — a signal that this campaign is not geographically limited. India, as one of the world’s largest Siemens software consumers, is equally in scope.

Frequently Asked Questions

Is my Siemens Software Center automatically patched?

If SSC is open and internet-connected, it will update automatically the next time it is launched. However, if the application is not opened regularly (common on infrequently-used engineer laptops), the update will not be applied. You must actively verify the version is 4.0.9.8 across all endpoints — do not assume auto-update has run.

Does this affect PLC firmware, TIA Portal, or SIMATIC hardware directly?

CVE-2026-110936 affects Siemens Software Center, the update management client, not PLC firmware, TIA Portal itself, or SIMATIC hardware. However, an attacker who achieves code execution on an engineer workstation via this flaw has a foothold that can be used to attack those adjacent systems. Treat a compromised SSC host as a potential pivot point for the entire OT network.

We don’t use SSC — do we need to do anything?

If your organisation does not use Siemens automation products, you are not directly affected. However, third-party contractors, system integrators, and remote OT vendors who connect to your network may have SSC installed. Audit contractor laptops and verify that any device with OT network access is clean before the next on-site visit.

How does ClickFix evade our existing security controls?

ClickFix campaigns are specifically designed to bypass signature-based AV (by using a signed legitimate binary), email gateway scanning (the malicious DLL is often hosted on a legitimate file-sharing service), and user training that focuses on malicious attachments (the “fix” prompt appears in-browser or in a legitimate-looking notification). Behavioural EDR, DLL load telemetry, and zero-trust application control are the controls that catch it — perimeter defences alone will not.