Siemens Software Center CVE-2026-110936: fix added 17 October, exploitation noted 19 October (read 20 October)

The advisory was published on 15 October and said nothing of exploitation until 19 October

Siemens published its security advisory SSA-580366 on Thursday 15 October 2026. Remediation was added on Saturday 17 October, 2 days later (derived). A link to a Siemens blog post saying that attackers are exploiting the flaw, CVE-2026-110936 in Siemens Software Center, was added on Monday 19 October, 4 days after publication and 2 days after the fix text (derived from the revision dates). The advisory page as read on 20 October carries two base scores for the flaw, 6.7 on CVSS v3.1 and 8.4 on CVSS v4.0. The two news reports on which this briefing started print only the second.

What that does not establish. It does not say when Siemens learned of the attacks, when they began, or whether the 15 October advisory was a response to them: a revision note records when a page changed, not when anyone knew something. It does not say when version 4.0.9.8 was released. Siemens's blog says Siemens fixed the weakness in that version and published the advisory on 15 October; the advisory's own history says remediation was added on 17 October, and neither page gives a release date. And it does not show that the first revision hid anything: I could not retrieve that revision, so what it said is read from the revision history, which lists only two later additions.

Revision history of Siemens advisory SSA-580366, as printed on the HTML page and in the machine-readable CSAF file (both read 20 October 2026), with what each revision left a reader unable to tell

Revision and date	Siemens's note, exactly	What a reader of that revision could not tell
V1.0, Thursday 15 October	Publication Date	Whether a fixed version existed (remediation was added in V1.1), and whether anything was being exploited (inferred from the history: no later note adds a correction)
V1.1, Saturday 17 October	Added remediation for Siemens Software Center	That anyone was exploiting the flaw: the blog is dated 19 October and the reference to it was not yet on the page
V1.2, Monday 19 October	Added reference to blog post about active exploitation of the vulnerability	When the exploitation began, how many systems, which sectors or countries, or what the malware did: the blog does not say

The current state of the records in this briefing was read at 11:47 BST on Tuesday 20 October 2026 and re-read, unchanged, at 12:06 BST; any of it can be overtaken. Siemens wrote both the advisory and the blog and sells the product. Forescout and Huntress, whose reports bear on the campaign, sell security products and publish threat research.

What Siemens says happened, in its own words

Siemens Software Center downloads, installs, activates and updates purchased Siemens software and starts free trials, according to the advisory's product description. The flaw is filed under CWE-427, Uncontrolled Search Path Element. The advisory says the application "loads dynamic-link libraries (DLLs) from an uncontrolled search path", so that "an authenticated local attacker" who places a crafted library in a folder it searches gets code running with the program's privileges. The affected range is all versions below V4.0.9.8. Siemens's download page, which is undated, now describes version 4.0 and says older versions will not be supported after 6 months.

The blog post of 19 October says Siemens "has validated that there is an active exploitation" of the flaw. The attackers used "a genuine copy of Siemens Software Center with a valid signature" and placed their own files next to it. They chose it, Siemens says, because it is signed and trusted, and because version 3.5.8.7, "the latest version at the time", loaded helper files from its own folder without checking them. The program itself was not modified; the malicious code was in the library files the attackers supplied. The blog says the attackers distributed the signed program with their files "outside official channels", and gives its scope statement in one sentence: "No Siemens system, product or update channel was breached to our knowledge." It lists three network indicators and two file hashes, which this briefing does not reproduce, and tells defenders to detect on the folder and the behaviour, because "the file itself is genuine".

The weakness class is old and documented. Microsoft's DLL search order page says that when an application loads a library without a full path, Windows searches a defined list of folders, and that for an unpackaged application the list includes the folder the application was loaded from. Its security page says that if an attacker gains control of a searched folder they can place a malicious copy there, which it calls a DLL preloading or binary planting attack, and tells developers to give a fully qualified path or to use the load flags that fix the search order. Siemens does not say how 4.0.9.8 changed the way the program loads these files.

Romulus is a delivery panel, and the link to Siemens rests on Siemens's own line

ClickFix lures, as Huntress and Forescout describe them, trick a visitor into pasting and running a command on their own machine. The blog's threat actor line reads "Romulus multi-platform ClickFix campaign". Forescout's post of 15 October, the day Siemens published the advisory, describes ROMULUS as a "multi-payload" ClickFix delivery platform, found while investigating an incident, names six server addresses running its panel, and says "The identity of the operator behind the platform and common ownership of the malware families are unknown." It adds that the panel may be a private tool, a commercial service, an affiliate framework, or software copied between operators. Forescout's post does not mention Siemens, and neither does Huntress's report. The connection I could check is one overlap: the address Siemens gives as the distribution channel for the malware bundle is among the six Forescout lists, where Forescout says it did not analyse that host individually. I have not reproduced the address. So "linked to Romulus" means linked to a delivery panel that several operators may run, not to a named actor.

The same pattern appears in Huntress's report of 28 September, covered on this site in Two of at least 40 ClickFix incidents came through a custom GPT: a signed program from Canon, then one from Stardock, loading a patched library supplied by the attackers, in at least 40 incidents Huntress responded to. Huntress wrote that it is "highly likely other signed applications are being abused the same way" and that "Detections tied to Canon or Stardock names will miss the next swap." Siemens Software Center is not in that report, and Siemens's blog came 21 days after it (derived: 28 September to 19 October). How victims reached the lure in the Siemens case is not stated, so nothing here shows that it involved the custom GPT route Huntress described.

Two scores for one flaw, and a privilege assumption the campaign did not need

The advisory and the CVE record, filed by Siemens as the CVE Numbering Authority, give the same two vectors. On CVSS v3.1 the base score is 6.7, band medium, and on CVSS v4.0 it is 8.4, band high. In both vectors the attack vector is local, the complexity is low, no user interaction is needed, and the privileges required are high. I recomputed both (derived). The v3.1 score reproduces by hand from the published formula: exploitability 0.8, impact 5.9, base 6.7, matching NVD's figures. The v4.0 score reproduced as 8.4 in an open-source calculator, the Python cvss package. The same v3.1 vector with privileges required set to none would score 8.4 (derived), so most of the gap between the two v3.1 numbers is the privilege assumption.

Three details change what a reader sees. The machine-readable CSAF file that Siemens publishes for the advisory carries only the v3.1 score, 6.7, labelled medium; the v4.0 score is on the HTML page and in the CVE record. NVD's entry was marked "Awaiting Analysis" when read, and the scores on it are Siemens's, not NIST's. And the CVE record carries a CISA coordinator entry stamped 15 October at 14:44 UTC with three options: Exploitation none, Automatable no, Technical Impact total. When read, that stamp was 4 days 20 hours old (derived), the record's only reference is the advisory, and it does not mention the blog. CISA's Known Exploited Vulnerabilities catalogue, version 2026.10.16 with 1,748 entries, does not list the CVE as read on 20 October.

Inference, labelled as such. "Privileges required: high" scores a case where the attacker can already write to a folder the installed program searches. The campaign as Siemens describes it did not need that: it brought its own copy of the program and put its files beside it, and the blog's hunting advice points to Siemens executables "outside the default installation folder". On that description, whatever rights a user has to run a program from a folder they own would be enough. The blog does not say what rights the victims held, so the vector may overstate the barrier. The word "authenticated" has the same problem. In a ClickFix attack the person at the keyboard pastes and runs the command, so the victim supplies the local foothold.

Six labels that sound like controls

A label is a statement about a record. It is not a control on a machine. Each row below sets one label from the sources beside what it covers and what it does not.

Labels in the Siemens advisory, the blog and the press reports, what each covers, and what it does not (sources read 20 October 2026)

Label	What it covers	What it does not cover
"Authenticated local attacker", privileges high	A scoring condition: the attacker is already on the machine with high rights.	How the campaign ran. A ClickFix victim pastes the command, so the victim is the foothold. The rights the victims held are not stated.
"Valid signature", "signed and trusted"	Who published the executable, and that it is unaltered.	What the executable loads next. Siemens says the file itself is genuine, so a hash or signature test passes it.
"Updates automatically on next startup"	Installed copies fix themselves when the program runs.	Machines where it is never run. A copy the attacker brought. Whether such a copy updates before it loads its files is not stated.
"No Siemens system, product or update channel was breached to our knowledge"	Siemens's own systems, products and updates did not carry the attack.	Customers' PCs, the number infected, or what "to our knowledge" covers. Where the bundle was hosted is not stated.
"Romulus"	The name of a delivery panel, per Forescout.	Who ran this campaign. Forescout says the operator is unknown.
"CVSS 8.4"	The v4.0 base score, band high.	The v3.1 score of 6.7 on the same page, or any score of how likely exploitation is. Both news reports print only 8.4.

Method is separate from accusation. Nothing here suggests Siemens misled anyone: it published the advisory, fixed the product, named the attack and said what it could not claim. The point is narrower. A score, a signature and an automatic update each answer a question, and none of them answers the question the campaign asked: what does this signed program load, and from where?

Stated, and not stated

What Siemens's advisory, blog and the CVE records state, and what none of them states (read 20 October 2026)

Topic	Stated (source)	Not stated
The fix	Update to V4.0.9.8 or later; "All existing versions of SSC will be auto updated on next startup" (advisory V1.1).	The release date of 4.0.9.8; what changed in the loading; whether any build below 4.0.9.8 other than 3.5.8.7 was public. No release notes listing versions were found.
The exploitation	Siemens validated it; a genuine signed copy ran beside attacker files; 3.5.8.7 was the latest version at the time (blog).	When it began; the number of systems; sectors; countries, including the UK; the payload (The Hacker News's headline says remote access trojan, Siemens's blog names none); what the malware did.
The lure	ClickFix, Romulus, "Never paste a command from a web page" (blog).	How victims reached the page, what it said, or how the bundle reached the machine beyond "outside official channels".
Credentials	If a compromise is found, isolate the PC, stop the process first, remove the start-up entry and the task, and reset passwords (blog).	Whether any credential was taken.
The reporter	A researcher at Huntress Labs is credited for reporting the vulnerability (advisory).	When it was reported, or whether Huntress saw the attacks.
Official listings	Not in CISA KEV catalogue 2026.10.16; NVD awaiting analysis; CVE record last updated 17 October at 08:34 UTC (as read).	Whether CISA will list it, or whether the CISA coordinator entry will be revised.
Industrial or OT impact	Nothing.	Whether any victim ran the program on an engineering or OT network.

The five days, drawn to scale

The diagram draws the days from 15 to 20 October against four things a reader could have seen on the public record: the scores, the fix text, the exploitation note, and the CISA coordinator entry that says exploitation none. The advisory's revisions are dated by day only, so their bars start at the start of the day.

The UK: which clocks apply, and where each document stops

UK guidance is quoted below as read on 20 October 2026. The release date of 4.0.9.8 is not stated, so any clock counted from release is a range: from the advisory date of 15 October or from the remediation date of 17 October. Siemens's records do not say any victim is a UK organisation, or that any ran the program on a network that touches operational technology.

UK guidance as read on 20 October 2026 on ncsc.gov.uk and ico.org.uk, with where each stops for this flaw

Document	What it says	Where it stops here
Cyber Essentials requirements for IT infrastructure, v3.3, April 2026, pages 17 and 18	Updates that fix vulnerabilities the vendor describes as critical or high risk, or with a CVSS v3 base score of 7 or above, must be installed within 14 days of release. Automatic updates are to be enabled where possible.	Siemens's v3.1 score is 6.7, 0.3 below the line (derived). The document never mentions CVSS v4. Siemens's CVE record labels the v4.0 score HIGH, so whether an assessor counts this update in the 14 day class is not settled by the text (inference). The range is Thursday 29 to Saturday 31 October (derived).
The same document, malware protection, page 24	The allow listing option: "Only approved applications, restricted by code signing, are allowed to execute on devices."	A valid Siemens signature satisfies a signature test, and the attack used one. The text does not say whether approval is by publisher, folder or file.
NCSC update by default guidance, version 2.1, reviewed 1 May 2026	Operating system and applications should update automatically as soon as published, within 7 days. Internal software is 14 days. The timeframes apply "regardless of the vulnerability severity".	7 days from 15 October is Thursday 22 October and from 17 October is Saturday 24 October (derived). The timetable does not read either score.
NCSC responding to active exploitation	Read the vendor advisory, ask whether the vendor has released instructions for confirming compromise, investigate, update, and report a compromise to the UK reporting service. Its compressed timelines are keyed to CISA KEV listing.	Not listed in KEV as read. The page notes that KEV reports only exploitation that has already occurred. Siemens has issued detection instructions, so the page's first question is answered. Report at gov.uk/report-cyber.
NCSC guidance: phishing attacks, defending your organisation, version 2.0, reviewed 13 February 2024	Phishing mitigations "often place too much emphasis on users being able to spot phishing emails"; use a layered approach with training as one aspect, and a proxy to block known malicious websites.	It covers email phishing and does not mention paste-and-run prompts. How the lure reached victims here is not stated.
ICO personal data breach guide	A notifiable personal data breach must be reported within 72 hours of becoming aware of it, where feasible.	Siemens does not say personal data was taken. A confirmed infection on a PC that handles personal data starts the assessment.

Two further pages are worth a read. The NCSC's asset discovery guidance says the aim is to identify and monitor the hardware and software in the estate, and the active exploitation page adds that organisations should confirm they are not affected beyond known systems, which "can include shadow IT, developer environments, contractors or other embedded staff". Where the PC sits on an engineering network next to operational technology, the NCSC operational technology collection is the starting point for connectivity, but Siemens does not say any victim was such a site.

What to do, in the order worth doing

The order follows how fast each step shrinks the exposure and how much each depends on a label. Each item rests on a source named above or is marked as this briefing's own judgement.

What could not be verified

• The first revision. The Internet Archive holds a capture of the advisory dated 16 October, but it answered with a rate limit each time, so I could not read it. The first revision's content is inferred from the revision history.
• Release notes. I found no Siemens release notes listing the versions between 3.5.8.7 and 4.0.9.8, so the number of versions between them cannot be counted, and the release date of 4.0.9.8 is not stated by any source read.
• The indicators. The blog lists network indicators and hashes. I read them and have not checked or reproduced them.
• The CVSS v4.0 recomputation used an open-source calculator, not a Siemens or FIRST tool.
• The news reports. SecurityWeek (19 October, 19:15 BST by its page time) and The Hacker News (20 October) are secondary and were used only as pointers. Where they differ from Siemens's pages, this briefing follows the pages.

The question that exposes the gap

Your tools can tell you that a Siemens program is signed, genuine and, after the next launch, patched. Which of them asks where it is running from and what it just loaded?

Key facts