On 19 October 2026, Siemens confirmed that someone is actively exploiting a flaw in its Software Center. The detail that made us stop is not the flaw. It is that the executable launched on the victims' machines was a genuine copy of the Siemens program, with its digital signature correct and intact. The attacker forged nothing and breached nothing at Siemens: they dropped a file called archive.dll in the same folder. And the program, on start-up, loaded it.
The facts, with dates
The flaw is CVE-2026-110936, published on 15 October 2026 with a CVSS v4 score of 8.4 and classified as CWE-427, "uncontrolled search path element". In plain terms: the program does not properly restrict which folders it searches for the DLLs it needs. On 17 October Siemens updated its advisory to state that version V4.0.9.8 fixes it, and that every earlier version is affected. On 19 October it confirmed exploitation in the wild. On 20 October, CISA added it to its catalogue of known exploited vulnerabilities, with a US federal remediation deadline of 3 November.
Siemens was explicit: "No Siemens system, product or update channel was breached to our knowledge." The attackers obtained a legitimate, signed copy of the program and distributed it, together with their own malicious files, outside official channels. This is not a compromised supply chain. It is something more uncomfortable: a perfectly legitimate binary turned into a vehicle without being touched at all.
What a digital signature answers
A code signature answers two questions, and it answers them well: who built this file and whether it has changed since. In this case both answers were correct. The executable was Siemens' and it was intact. Whoever checked got the right answer.
The signature says nothing about a third question, which turns out to be the one that mattered: what that program will load once it runs. Windows resolves the libraries a program asks for by walking a list of folders, and the program's own folder is on that list. If somebody places a file there with the name the program expects, the signed executable loads it into its own process. From that moment, the attacker's code runs inside a process whose publisher is Siemens, with the same permissions. The signature covered the container. The contents arrived afterwards.
This is not meant as an indictment of Siemens. CWE-427 is one of the most repeated bug classes in desktop software, and it shows up every year in products of every size; Forescout, which published its research on 15 October into the delivery platform used in this campaign, also documented a trojanised installer leaning on a legitimate Stardock application for the same manoeuvre. What interests us is not who is to blame for the flaw, but what that flaw does to the controls you have in place.
Your publisher allowlist just approved this
If your fleet's application control policy says "allow whatever is signed by a known publisher" — the most common pragmatic setting, because it is the one that best survives contact with real users — this campaign passes the filter. Not because the control failed: because it did exactly what you asked of it. The executable was signed by a known publisher.
The same goes for the "is it signed?" column in your software inventory and for the mental check of whoever eyeballs a file before opening it. Both went green, and rightly so. Neither of the two was designed to answer the question the machine depended on.
The policies that do resist this manoeuvre are those that authorise by cryptographic hash or by path, rather than by who signed. The price of those policies sits in the maintenance: they require maintaining a list that changes with every update of every program, and, from what we have seen setting them up, most small companies that switch them on end up switching them off, because the day a legitimate user cannot work, the user wins the argument. We already covered what it costs to maintain a hash list when we wrote the Windows blocked driver list is 1,702 hashes: an explicit list ages, and it ages on its own.
The vector says "local" and your patch queue misreads it
The vector published by Siemens is CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Two pieces of that string explain why the score stops at 8.4 and goes no higher: AV:L means the attack requires local access, and PR:H means the attacker already needs high privileges. On paper, a bad combination for the attacker.
That same reading is what your patch queue does on a Tuesday morning: local, needs privileges, software only three people in engineering have. Bottom of the list. What the vector cannot express — it is not built for it — is that the campaign hands over the local access for free. Somebody persuades an employee to download a bundle and run it on their own machine, and that gesture covers the local-access requirement. The high-privilege one is supplied by the install itself: a package that installs is a package that asks to elevate. The precondition that made the attack hard is supplied by the user, at no cost, in the part of the chain CVSS does not look at.
It is the same rule we applied back when Acronis needed local access and you were selling it: the vector ranks the vulnerability; the exploitation catalogue ranks the day. While a flaw is theoretical, the vector governs and a local 8.4 can wait for the monthly cycle. The day it enters CISA's catalogue, somebody has already shown the preconditions hold in the real world, and "requires local access" stops being a reason to wait. This one entered on 20 October.
We need not dwell on how the employee is persuaded to run the bundle: we covered it recently looking at the Mac version of the same technique, in the malware you paste into the terminal yourself. The operating system changes and the window changes; the idea of having the victim perform the first step with their own hands is identical.
What does leave a trail
If the file's identity cannot tell them apart, what is left is behaviour. And there the manoeuvre is genuinely odd, because legitimate software installed by the IT department almost never behaves this way. These are the signals we watch, in order of usefulness:
- A signed executable running from a folder the user can write to. Downloads, the user profile, a temp folder. Most software installed by IT lives in
Program Files, where the user cannot write; this manoeuvre needs precisely the opposite, because the attacker has to be able to drop their file alongside. - That executable loading an unsigned module from its own folder. It is the most specific of the three signals and the one that turns suspicion into certainty. A commercial product loads its own libraries, and those normally come signed by the same publisher.
- The chain of who launched what. A browser or a command interpreter that ends up starting an installer is a sequence that explains itself when it is legitimate, and that is hard to explain when it is not.
Here comes the part that does not suit us commercially and that we will say anyway: the first signal is noisy. There is legitimate software that runs from user folders — updaters, portable tools, the installer somebody downloaded with permission — and if you turn that rule on untuned, alerts arrive every week. A dashboard full of alerts nobody triages is not detection: it is a screen that is switched on. What separates one from the other is somebody reading them and knowing how to dismiss them.
Three questions for this afternoon
None of the three is a project. All three can be answered today, and the painful part is not answering them: it is discovering that you cannot.
The part that is on us
When we set up managed EDR/MDR we do not promise to block everything, because the day you over-block, the customer asks you to switch it off. What we maintain is the boring part: rules that watch what the process does, not the label on the file, tuning those rules against each customer's actual software so the noise drops to something triageable, and somebody reading the alerts at an hour when nobody else is reading anything.
On the limit, which comes up in every meeting: nobody can guarantee that an agent would have stopped archive.dll on day one. What genuinely changes is the day after. With process and module telemetry retained, "did this run here?" is answered in minutes across the whole fleet; without it, it is answered in weeks and prefixed with "we think not". That difference — between knowing and assuming — is what ends up deciding whether an incident is a bad afternoon or a bad quarter.
If you want to review with us what your application policy authorises today and what telemetry you are keeping, it is a short conversation: get in touch. And if you only do one thing after reading this, make it the second question in the table. It is the one that hurts most and the one that is fixed soonest.
What the signature never answered
The lesson of this campaign fits in one sentence, and it holds for far more than a Siemens product: the signature answers who made the file, and nothing about what that file does once opened. We have spent years building controls on the first question because it is cheap to check and gives a clean answer. The second costs more, messes up the dashboard and requires somebody to look. On 19 October it became clear which of the two was holding the machine up.
Sources. The CVE-2026-110936 data — publication on 15 October 2026, CVSS v4 score of 8.4, vector CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, CWE-427 classification ("uncontrolled search path element"), fix in version V4.0.9.8 with all earlier versions affected, advisory update on 17 October, Siemens' confirmation of in-the-wild exploitation on 19 October, addition to CISA's KEV catalogue on 20 October with a federal deadline of 3 November 2026, and the name of the malicious file archive.dll — come from the Siemens advisory and its compilation at Rescana and SecurityWeek. The Siemens quote "No Siemens system, product or update channel was breached to our knowledge", the fact that attackers obtained a legitimate signed copy and distributed it with malicious files outside official channels, the mechanism (the program does not properly restrict where it searches for DLLs, so a DLL planted in one of those folders executes with the same privileges as the program) and the Forescout research published on 15 October 2026 into the delivery platform used — including the trojanised installer leaning on a legitimate Stardock application for the same manoeuvre — come from the same sources. The behaviour of the Windows library search order, which includes the executable's own folder, is documented operating-system behaviour. Reading AV:L and PR:H as the two pieces capping the score, the argument that the delivery chain supplies the local-access precondition for free, the rule "the vector ranks the vulnerability and the exploitation catalogue ranks the day" — already applied in earlier entries of this blog — the three behavioural signals, the warning about the noise the first of them generates, and the three questions in the table are our own judgement and method, not claims made by Siemens, by CISA or by any of the sources above. everyWAN provides managed EDR/MDR services: the conflict of interest is declared. Cover photo: "My view 090909,09 09", by Håkan Dahlström, Wikimedia Commons, CC BY 2.0.
Microsoft 365
ES 
CAT 
EN