The signed binary was fine: Siemens Software Center CVE-2026-110936 and the DLL next to it

On 19 October 2026 Siemens confirmed that CVE-2026-110936 had been used in real attacks. The vulnerability is a DLL search-path problem in Siemens Software Center, the application customers use to download, install, activate and update licensed Siemens products. NVD describes it as loading dynamic-link libraries from an uncontrolled search path, allowing an authenticated local attacker to place a crafted DLL where the application will find it and execute code with the application's privileges.
Siemens scores it 8.4 under CVSS v4.0. The affected range is every version before V4.0.9.8. CISA added it to the Known Exploited Vulnerabilities catalogue on 20 October 2026 with a remediation deadline of 3 November 2026.

What actually got abused

The attack did not tamper with Siemens software. Reporting on the campaign describes a bundle containing a genuine, correctly signed copy of Siemens Software Center alongside attacker-supplied dynamic libraries in the same directory. The application, running as designed but without verifying the auxiliary files it loads, executed the attacker's code on startup.
Siemens states that the program itself was not modified, that its systems, products and update channel were not compromised to its knowledge, and that the malicious bundle was not distributed through official channels.
That distinction matters for detection. Signature verification of the main executable passes. File integrity monitoring scoped to program directories may show nothing unusual if the attacker's files are simply new, not modifications. The compromise lives in a directory listing, not in a hash comparison.

Delivery

The bundle was distributed through ClickFix-style lures, in which a web page instructs the visitor to paste a command into a Run dialog or a terminal to "fix" a problem. ClickFix has become a common initial access method for commodity malware because it converts a browser visit into local execution using the user's own hands, bypassing controls that would otherwise block a download-and-execute chain.
For Software Center specifically, the target audience is engineering and operations staff who are accustomed to installing vendor tooling. The lure does not have to be sophisticated to work against someone whose job involves downloading installers.

Why a signed-product ecosystem makes this harder

Siemens environments are full of legitimate reasons for a directory to contain a vendor binary and several DLLs. Software Center ships with its own dependencies. When an analyst opens a folder to check whether the files look right, "a real Siemens executable plus supporting libraries" is exactly what a correct installation looks like.
The check that does discriminate is location and provenance: did these files arrive from the vendor's delivery mechanism, do their timestamps match the rest of the installation, and is there a record of who installed the bundle and when? Those questions are answerable, but only if someone recorded the installation in the first place.

Investigation steps that hold up

Start from the delivery event rather than the filesystem. ClickFix execution usually leaves traces in user-facing places: recent Run-dialog history, PowerShell console history, browser downloads, and EDR process telemetry showing a shell launched by a browser process. A child process of a browser that is a shell or a script host is the highest-value signal available here.
Then check Software Center installation directories for files that are not accounted for by the vendor package. Pay particular attention to DLL names that resolve to a file in the application directory rather than in System32, which is the pattern uncontrolled search-path loading produces.
Then review what the machine had access to. Software Center is used by people who administer industrial systems, and those endpoints frequently hold project files, engineering credentials and VPN profiles. A likely payload objective for this kind of bundle is credential access rather than immediate lateral movement.

Remediation

Upgrade to V4.0.9.8 or later. Siemens' advisory page SSA-580366 carries the vendor detail, and the advisory timeline is worth noting: first published 15 October without mention of exploitation, updated 17 October with the fixed version, then updated again on 19 October with a blog post confirming active exploitation and listing indicators of compromise.
Restrict what Software Center is allowed to load, where the product supports it. Application allow-listing that permits only signed binaries still permits this attack, because the signed binary is the legitimate one; the malicious component is unsigned code that the signed application loads. The allow-list has to cover loaded modules, not just executed files.
Treat engineering workstations as privileged endpoints. They reach into control networks, they hold vendor credentials, and they are the machines users install software on by design.

The pattern worth generalising

DLL search-path vulnerabilities are old and unglamorous. They remain effective because the defence that people reach for, "the application is genuinely signed by the vendor", answers a different question from "what did the application load after it started".
For vendors who distribute installers that run with elevated privilege, verifying the integrity of the auxiliary components at load time is available and inexpensive. For defenders, the compensating control is module-level allow-listing and installation provenance on the hosts where vendor software is installed.

References

• Siemens security advisory SSA-580366, with updates of 15, 17 and 19 October 2026 and the accompanying product security blog post
• NVD entry for CVE-2026-110936, CWE-427, CVSS v4.0 8.4
• CISA Known Exploited Vulnerabilities catalogue entry added 20 October 2026
• Canadian Centre for Cyber Security advisory AV26-1063
• Tencent Cloud developer summary of the incident, 20 October 2026