SiteGuard and Siemens Software Center Flaws Exploited: KEV Guide

On 20 October 2026 CISA added two exploited flaws to its Known Exploited Vulnerabilities catalog: CVE-2026-106931, a command injection in the SiteGuard Server Edition host WAF that runs commands as root or SYSTEM, and CVE-2026-110936, a DLL search path flaw in Siemens Software Center abused in ClickFix attacks. Save SiteGuard diagnostics, then update both products.

These two bugs have little in common technically. One lives inside web servers that hosting companies across Japan run on behalf of their customers. The other lives on Windows desktops and is being carried onto machines that never had Siemens software installed. What links them is the KEV listing date, a short federal deadline, and a shared lesson: software that people trust by default, a security module or a signed vendor binary, is exactly what attackers want to run their code through.

This post covers both in depth: exact affected and fixed versions, the scores each source gives, the indicators of compromise Siemens published, how the Siemens bug connects to a wider ClickFix delivery platform called ROMULUS, and the detection and remediation commands for Linux, FreeBSD and Windows.

What happened

EG Secure Solutions, the Tokyo company that makes SiteGuard, published an urgent alert on 14 October 2026 saying that an OS command injection in the statistics feature of SiteGuard Server Edition was already being exploited. JPCERT/CC issued alert JPCERT-AT-2026-0032 and the Japan Vulnerability Notes portal published JVN#88474777 the same day. The vendor had told customers with direct support contracts on 29 September, more than two weeks before the public notice.

A day later, on 15 October, Siemens ProductCERT published SSA-580366 for a DLL side loading flaw in Siemens Software Center, the Windows application Siemens customers use to download, install, activate and update licensed software. The first version of the advisory did not mention exploitation. On 17 October Siemens added the fix, version 4.0.9.8. On 19 October Siemens published a ProductCERT news post titled "Active exploitation of CVE-2026-110936 in Siemens Software Center", with indicators of compromise, and linked it from the advisory.

On 20 October CISA added both CVEs to KEV, alongside four Plex Media Server CVEs. The Hacker News counted six additions that day. SiteGuard received a three day due date of 23 October and is marked as requiring forensic triage under Binding Operational Directive 26-04. Siemens Software Center received a due date of 3 November.

Timeline

All times are as published by the cited source. Where a source gives only a date, the time column is blank.

Technical details

CVE-2026-106931: SiteGuard Server Edition

SiteGuard Server Edition is a host based web application firewall. Instead of sitting in front of a server as a separate appliance, it is installed into the web server itself as a module for Apache httpd, Nginx or Microsoft IIS. JVN describes it as a WAF "integrated into a web server". That placement is why the bug is serious: the module runs with the privileges of the server it protects, and the vulnerable code sits in a feature that collects statistics about the traffic it inspects.

Affected and fixed versions

The vendor alert, JVN and JPCERT/CC agree on these ranges. The machine readable CVE record encodes the IIS exception in a way that can read oddly: it lists Ver3.10 as the start of an unaffected range and Ver4.00 Update5 as the point where versions become affected again. That matches the advisories if you read it as "Ver3.10 through Ver4.00 Update4 are unaffected", but a scanner that parses the record naively could mislabel some IIS builds. Use the vendor table above as the source of truth.

What the advisories do and do not say

The advisories describe the bug class and location and nothing more. There is no public description of the request or input that triggers the injection, no exploit, and no indicators of compromise. The Hacker News said no further details on the exploitation activity were available. BleepingComputer reported that the attacker, methods and victims are unknown.

The scoring deserves a careful read. Both CVSS vectors use attack vector Local and privileges required Low. In plain terms, the scoring assumes an attacker already has some foothold on the host, or some low privileged path to reach the statistics feature, before the injection gives them root or SYSTEM. None of the public sources explain how attackers in the wild obtained that starting position. The vendor still calls it urgent, JVN calls it critical, and CISA set the shortest KEV timeline its directive allows plus a forensic triage requirement. Treat the score as a description of preconditions, not as a sign that the risk is moderate.

Scale figures come from press, not from the advisories. JPCERT/CC says the product is widely used in Japan. BleepingComputer reported that the vendor claims more than 1.5 million protected websites. BleepingComputer also cited WordPress.org figures for a SiteGuard WordPress plugin; that plugin is a separate product, and none of the advisories lists it as affected.

CVE-2026-110936: Siemens Software Center

Siemens Software Center is a Windows application that handles download, installation, activation and updates for Siemens licensed software and trials. The flaw is a classic uncontrolled search path: when the program starts, it looks for some of the DLLs it needs in its own folder and loads whatever it finds there, without checking them.

Affected and fixed versions

The jump from 3.5.8.7 to 4.0.9.8 is how Siemens reports it; neither the advisory nor the news post explains the numbering.

How the attack works, in plain language

The important detail is that the attackers did not break into Siemens. According to Siemens, the program itself was not modified and "No Siemens system, product or update channel was breached" to its knowledge. Instead the attackers took a genuine, validly signed copy of SiemensSoftwareCenter.exe and shipped it inside their own installer, next to DLL files they wrote. When the vulnerable version starts, it loads those DLLs from its own folder, so the attacker's code runs inside a process that carries a real Siemens signature.

This is why the CVSS vector says high privileges are needed while the real world risk is high. The vector models an attacker who must write into the folder of an existing installation. In the campaign, the attackers bring the whole folder with them, so the only thing they need is a user who runs their installer. Siemens says the malicious bundle was distributed outside official channels as AllMyBasic.msi.

Siemens links the attacks to the ROMULUS multi platform ClickFix campaign. ClickFix is a social engineering pattern in which a web page, often dressed up as a CAPTCHA or a fix for a fake error, tells the visitor to paste a command into the Windows Run box, a terminal or PowerShell. Our explainer, what is ClickFix and how do I stop it, covers the pattern in general. Siemens' own advice to individuals is to never paste commands from web pages into Win+R, the Run box or PowerShell.

Indicators of compromise published by Siemens

All values below are as listed in the Siemens ProductCERT post of 19 October, defanged as Siemens published them.

Host artifacts Siemens lists:

• A folder named SM Software Provisioning Service inside AppData\Local\Programs, created by the malware.
• Files activate.bak and statinfosta.DB next to SiemensSoftwareCenter.exe.
• A folder FTSuite inside AppData\Local containing ftc.uml.
• "Siemens Software Center" entries in start up apps or Task Scheduler on a PC where it was never installed.
• SiemensSoftwareCenter.exe running from AppData\Local\Programs and launched by msiexec.

Siemens makes a point worth repeating: the executable is genuine, so its hash and signature will look clean. Detection has to rely on where it runs, what launched it and what sits beside it. Siemens did not publish registry key names or specific scheduled task names.

The ROMULUS connection and the wider signed binary campaign

Siemens names ROMULUS but gives no further detail on it. Two earlier reports fill in the picture, and neither of them mentions Siemens.

Forescout Vedere Labs published an analysis of ROMULUS on 15 October. It describes a reusable delivery backend with a login panel, a stats page counting "unique installs" and "all runs", and two kinds of endpoint: one path serves a PowerShell staging script, and a second path with the same 12 character hexadecimal token serves a trojanized MSI. Forescout identified six IP addresses running ROMULUS instances. Its IOC list includes 96.62.224[.]81, 86.109.75[.]7, 151.240.151[.]223, 23.94.145[.]224, 93.152.224[.]118 and 2.27.248[.]127.

That last address is the one Siemens lists as the inactive distribution channel for AllMyBasic.msi. The overlap is visible by comparing the two primary sources; SecurityWeek also reported that one ROMULUS server is the one Siemens identified as the distribution server. Forescout could not identify who operates ROMULUS and suggested it might be a private panel, a commercial service, an affiliate framework or copied software.

Forescout documented two delivery routes. Route A used a trojanized IconEdit2Turb.msi posing as the "Stardock Smart DeElevation Tool", which runs a signed DeElevate64.exe that loads a patched DeElevator64.dll, which hands off to a loader named I++u.dll. Route B pulled a password protected archive, unpacked an executable of roughly 882 MB padded to dodge size limits, and ended in LegionLoader, a loader active since 2019 that Forescout says is also known as CurlyGate, RobotDropper and Satacom, with command and control at smashshape[.]com.

Huntress described the Stardock route earlier, in its 28 September report on malicious ChatGPT custom GPTs that sent users to a fake CAPTCHA page on Google Sites. Huntress responded to at least 40 incidents tied to that page. Its first wave side loaded through a Canon signed COTFileReadApp.exe with a patched ceiinfolog.dll and a payload DLL rdCore.dll; the second wave switched to Stardock's DeElevate64.exe. Persistence used an HKCU Run value and a scheduled task with the same name, Canon Configuration Reader in the first wave and Stardock DeElevation Tool in the second. The final payload was a remote access trojan with remote desktop, camera, microphone and audio capture, browser data access and file search.

The Siemens case fits the same pattern: a legitimate signed vendor binary, an installer that drops it in a per user programs folder, malicious DLLs beside it, and a ClickFix lure to start the chain. SecurityWeek noted that the overlapping infrastructure and the similar technique suggest the Siemens binary may have been added to the same toolkit, and framed that as inference. We have not seen a primary source that ties the Siemens payload to the Huntress RAT or to LegionLoader, so do not assume the final payload is the same.

Selected hashes from these reports that defenders can add to hunting, as published:

Huntress specifically advises against globally blocking the legitimate Canon or Stardock executables. The same logic applies to Siemens Software Center: block the context, not the vendor's binary, or you will break the real product for the people who use it.

Who is affected

The last row is the one most teams will miss. For the Siemens flaw, the population at risk is not limited to Siemens customers. It is anyone who can be persuaded to paste a command or run an installer.

What changed since first reports

• Siemens exploitation status. SSA-580366 V1.0 on 15 October did not mention exploitation and gave no fixed version. V1.1 added 4.0.9.8 on 17 October and V1.2 linked the exploitation post on 19 October. Early readers of the advisory saw a medium 6.7 CVSS 3.1 local bug with no fix.
• SiteGuard exploitation date. The public alert came on 14 October, but the vendor told contracted customers on 29 September. Some Japanese coverage reads this as exploitation starting before the public notice; the vendor alert itself says only that exploitation has been confirmed.
• Federal urgency. SiteGuard went from a Japan focused alert to a KEV entry with a three day deadline and a forensic triage flag on 20 October.
• CVE enrichment. On 21 October both CVE records gained CISA ADP data with the KEV listing and SSVC ratings. Feeds that pull CVE data only once a day may have shown neither entry as exploited until then.

What to do now

The order matters for SiteGuard: preserve evidence first, then fix. For Siemens Software Center, hunt first on every Windows estate, then update real installs.

1. Find every SiteGuard Server Edition install

Package names and install paths vary by distribution channel and hosting panel, so search broadly and case insensitively.

On Linux with RPM or Debian packages:

rpm -qa | grep -i siteguard
dpkg -l | grep -i siteguard

On FreeBSD:

pkg info | grep -i siteguard

Check whether the web server loads a SiteGuard module:

# Apache httpd
apachectl -M 2>/dev/null | grep -i siteguard
grep -ril siteguard /etc/httpd /etc/apache2 /usr/local/etc/apache24 2>/dev/null

# Nginx
nginx -V 2>&1 | grep -io siteguard
grep -ril siteguard /etc/nginx /usr/local/etc/nginx 2>/dev/null

On Windows servers running IIS:

Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*,
  HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* |
  Where-Object { $_.DisplayName -like '*SiteGuard*' } |
  Select-Object DisplayName, DisplayVersion, InstallDate

Confirm the version against the table above using the product's web admin console or the delivery documents from your support contract. If a hosting provider runs SiteGuard for you, ask them directly which version and whether statistics is enabled. You will not be able to see it from a shared hosting account.

2. Preserve diagnostic information before you change anything

The vendor, JVN and JPCERT/CC all warn that updating or patching may erase traces of an attack. Before you update:

1. Open the SiteGuard Server Edition web admin console.
2. Go to Diagnostic Information, then Download Diagnostic Information.
3. Store the file somewhere off the host, with a note of who collected it and when.

If you are a federal agency, BOD 26-04 forensic triage also applies. CISA's implementation guidance asks for volatile data first (memory, caches, in transit data), then persistent data, with a log of each item's source, time and collector, and suggests evidence collection and patching within 2 to 24 hours of the KEV addition. Non federal teams can use the same order.

A simple snapshot of host state before the change, on Linux:

mkdir -p /root/ir-siteguard && cd /root/ir-siteguard
date -u > collected_at.txt
ps auxwwf > ps.txt
ss -tunap > sockets.txt
crontab -l -u root > cron_root.txt 2>&1
ls -la /etc/cron.* /var/spool/cron* > cron_dirs.txt 2>&1
last -Faiw > logins.txt 2>&1
find / -xdev -newermt "2026-09-01" -type f \( -path /proc -prune -o -print \) 2>/dev/null > new_files_since_sep.txt
tar czf weblogs.tgz /var/log/httpd /var/log/apache2 /var/log/nginx 2>/dev/null
sha256sum * > manifest.sha256

Copy the folder off the host before you patch. Adjust log paths for your distribution and hosting panel.

3. Fix SiteGuard

1. Upgrade to Ver8.00 Update5 (Apache, Nginx, IIS) or Ver7.00 Update6 (FreeBSD Apache and Nginx).
2. If you cannot upgrade quickly, ask your support desk or reseller for the vendor patch that replaces the statistics processing files. It is available for end of life versions.
3. JPCERT/CC states that disabling the statistics feature avoids the vulnerability and that the vendor's latest information includes the steps. The vendor alert page and JVN describe only the update and the patch. Treat disabling statistics as a stopgap you confirm with the vendor, not as a fix.
4. Restart the web server and confirm the new version from the admin console.

4. Look for compromise on SiteGuard hosts

No IOCs have been published, so this is a behavioral hunt. Focus on what a root or SYSTEM command from the web tier would leave behind.

• Processes whose parent is the web server or a SiteGuard component that should not exist: shells, curl, wget, python, perl, certutil, powershell.
• New or changed cron entries, systemd units, scheduled tasks and services since late September.
• New local users, new SSH keys in authorized_keys, sudoers changes.
• Outbound connections from the web server host to addresses you do not recognize.
• Web shells or recently modified files under document roots.

ps -eo pid,ppid,user,etimes,cmd --forest | grep -B2 -A5 -Ei 'httpd|apache2|nginx' | grep -Ei 'sh -c|bash|curl|wget|python|perl|nc '
systemctl list-unit-files --state=enabled --no-pager | sort > units_now.txt
find /root /home -name authorized_keys -newermt "2026-09-01" -ls 2>/dev/null
find /var/www /usr/share/nginx /usr/local/www -type f -newermt "2026-09-01" \( -name '*.php' -o -name '*.jsp' -o -name '*.aspx' \) -ls 2>/dev/null

On IIS hosts, review Security event 4688 (process creation) for children of w3wp.exe, new services (System event 7045) and new scheduled tasks (TaskScheduler Operational event 106).

If you find something, isolate the host, keep the evidence, and assume any secrets on the box are exposed: database passwords, TLS private keys, API tokens in configuration files, and any credentials the hosting panel stores. Rotate them after you rebuild. For a hosting provider, that includes thinking about every customer site the host served.

5. Hunt for the Siemens Software Center campaign on Windows

Run this whether or not you use Siemens software. First, find every copy of the executable outside the normal install location:

Get-ChildItem -Path 'C:\Users\*\AppData\Local\Programs' -Recurse -Filter 'SiemensSoftwareCenter.exe' -ErrorAction SilentlyContinue |
  ForEach-Object {
    [pscustomobject]@{
      Path    = $_.FullName
      Version = $_.VersionInfo.FileVersion
      Signer  = (Get-AuthenticodeSignature $_.FullName).SignerCertificate.Subject
      Created = $_.CreationTime
    }
  }

A valid Siemens signature here is expected and proves nothing. What matters is the location and what sits next to it. Check for the Siemens listed artifacts:

$users = Get-ChildItem 'C:\Users' -Directory
foreach ($u in $users) {
  $p = Join-Path $u.FullName 'AppData\Local\Programs\SM Software Provisioning Service'
  $f = Join-Path $u.FullName 'AppData\Local\FTSuite\ftc.uml'
  if (Test-Path $p) { "FOUND folder: $p" }
  if (Test-Path $f) { "FOUND file: $f" }
  Get-ChildItem (Join-Path $u.FullName 'AppData\Local\Programs') -Recurse -Include 'activate.bak','statinfosta.DB' -ErrorAction SilentlyContinue |
    ForEach-Object { "FOUND artifact: $($_.FullName)" }
}

Compare hashes of any AllMyBasic.msi or archive.dll you find with the Siemens values:

$bad = @{
  'f4d7c5321bb0d1bda439304a753bcf9b467b98ca53c7e9493b9c2c3451092e4a' = 'AllMyBasic.msi'
  '3fdcc7d7d049a89711fb31fb236940a1c5a09d899143ffd20c3c41fb1f2cf491' = 'archive.dll'
}
Get-ChildItem 'C:\Users\*\AppData','C:\Users\*\Downloads' -Recurse -Include 'AllMyBasic.msi','archive.dll' -ErrorAction SilentlyContinue |
  ForEach-Object {
    $h = (Get-FileHash $_.FullName -Algorithm SHA256).Hash.ToLower()
    if ($bad.ContainsKey($h)) { "MATCH $($bad[$h]): $($_.FullName)" }
  }

Look at persistence. Siemens did not publish task or value names, so search by product name and by the names Huntress published for the related campaign:

Get-ScheduledTask | Where-Object { $_.TaskName -match 'Siemens|Canon Configuration Reader|Stardock DeElevation Tool' } |
  Select-Object TaskName, TaskPath, @{n='Action';e={$_.Actions.Execute}}

Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run' |
  Select-Object * -ExcludeProperty PS*

# Recent Run dialog history, a common ClickFix trace
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU' -ErrorAction SilentlyContinue

If you use Microsoft Defender for Endpoint or a similar EDR with a query language, hunt for the launch pattern Siemens describes. An example in KQL:

DeviceProcessEvents
| where Timestamp > ago(45d)
| where FileName =~ "SiemensSoftwareCenter.exe"
| where FolderPath has @"\AppData\Local\Programs\"
| where InitiatingProcessFileName =~ "msiexec.exe"
| project Timestamp, DeviceName, AccountName, FolderPath, InitiatingProcessCommandLine

And for DLLs loaded by that process from a user writable folder:

DeviceImageLoadEvents
| where Timestamp > ago(45d)
| where InitiatingProcessFileName =~ "SiemensSoftwareCenter.exe"
| where FolderPath has @"\AppData\"
| summarize count() by DeviceName, FileName, FolderPath, SHA256

Search proxy, DNS and firewall logs for the network indicators, including the inactive distribution IP, because Siemens notes that systems which downloaded from it may still be infected:

grep -E '96\.62\.218\.59|2\.27\.248\.127|wizardexpensive\.com' /var/log/squid/access.log* /var/log/named/*.log 2>/dev/null

Forescout also recommends hunting for PowerShell started with -NoProfile, -ep bypass or -w hidden together with a URL, for URLs that use decimal IP notation such as 1450003207, and for silent MSI installs from %TEMP% followed by new executables.

6. Contain and clean a Siemens hit

Siemens' order for a suspected compromise is: isolate the PC and stop the process first, then remove the start up entry and scheduled task, then reset passwords, then follow your incident response process. Huntress gives the same order for the related campaign and explains why: in its cases a script re-created the Run value and task if they were removed while the implant was still running.

Because the related RAT documented by Huntress could read browser data, treat browser stored passwords and session cookies on an affected machine as exposed. Reset passwords from a clean device and revoke active sessions for that user's key accounts.

7. Update real Siemens Software Center installs

Real installations update to 4.0.9.8 automatically the next time they start. Check that it happened:

Get-ChildItem 'C:\Program Files*','C:\Users\*\AppData\Local\Programs' -Recurse -Filter 'SiemensSoftwareCenter.exe' -ErrorAction SilentlyContinue |
  Select-Object FullName, @{n='Version';e={$_.VersionInfo.FileVersion}}

Any copy below 4.0.9.8 that has not started recently has not updated. Start it, or download the current version only from the official Siemens Software Center page.

8. Block the Siemens network indicators

New-NetFirewallRule -DisplayName 'Block SSA-580366 IOCs' -Direction Outbound -Action Block `
  -RemoteAddress 96.62.218.59,2.27.248.127

Add wizardexpensive.com to your DNS resolver or secure web gateway block list. Siemens lists the first two indicators as still active at the time of its post.

Open questions

• How SiteGuard attackers got their foothold. The CVSS vectors assume local, low privilege access. No public source explains how that was achieved in the attacks, whether through another flaw, a hosting control panel, a compromised customer account on a shared host, or something else.
• Who was targeted and how many. Neither EG Secure Solutions nor JPCERT/CC has described victims, sectors or scale.
• Whether the statistics workaround is official. JPCERT/CC says disabling statistics avoids the issue; the vendor alert as published centers on the update and patch.
• The Siemens final payload. Siemens names archive.dll and the ROMULUS campaign but does not name the malware family. Reports that tie it to LegionLoader or to the Huntress RAT are inference from shared infrastructure.
• How many other signed binaries are in the toolkit. Huntress said it believes signed programs from other vendors are likely being misused too. Expect new names.
• KEV counts. Trackers report different totals for 20 October depending on how the four Plex CVEs are counted. The Hacker News reported six.

What would have helped

Practices any team can use

Know which security software runs inside your web servers. A host based WAF is a module with the privileges of the server and its own features, schedulers and statistics jobs. It belongs in your asset inventory with an owner, a version and an update channel, just like the web server itself. Our guide to finding affected products fast with an SBOM covers the inventory side for the software you build.

Turn off default features you do not use. The SiteGuard flaw sits in a feature that is on by default. Many products ship reporting, telemetry and statistics modules enabled. Each one is code that runs with the product's privileges. Review defaults at install time and disable what you do not need.

Collect evidence before you patch. Both the vendor and CISA called this out. Build the evidence step into your patch runbook so it is not a judgment call under pressure: a scripted snapshot, a vendor diagnostic export where one exists, and a copy off the host.

Read the vendor alert, not just the CVE feed. SiteGuard customers with support contracts heard on 29 September. Siemens' exploitation update came as an advisory revision. A process that only reacts when a CVE score lands in a feed would have been two weeks late on SiteGuard and would have seen a 6.7 for Siemens.

Control where code can run on desktops. Application control that combines publisher and path rules helps here: allow a signed vendor binary from its real install location, and treat the same binary in a per user programs folder, launched by msiexec from a temporary folder, as suspicious. Windows Installer policy can stop standard users from running per user MSI installs at all, which removes the delivery step in this chain for most staff.

Make ClickFix hard to complete. Remove or restrict the Run dialog for standard users where your support model allows it, constrain PowerShell for non technical staff, and teach one simple rule: no legitimate website asks you to paste a command into Windows. Our ClickFix explainer has the details.

Detect on behavior, not hashes, when the binary is legitimate. Siemens, Huntress and Forescout all make this point. A signed executable will pass hash and signature checks. Its location, parent process and neighbouring DLLs are what give it away.

The same lesson shows up in other recent incidents: trusted components at the edge and on the desktop, a fix that exists, and a short gap that attackers use. See edge device zero days this month and our October 2026 incident roundup.

Where Safeguard fits

Be clear about scope first. SiteGuard Server Edition is a proprietary web server module and Siemens Software Center is a proprietary Windows desktop application. Safeguard is a software supply chain security platform. It does not run on desktops as an endpoint agent, it does not watch running processes, and it would not have detected a ClickFix lure or a side loaded DLL on a laptop. It would not have prevented either incident. Your EDR, application control and user training carry that part.

Where it does help is in the systems you build and operate:

• Knowing what is inside your images. SBOM and dependency scanning covers repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, with JSON results under ./output). The platform shows which projects contain a given component and version. If your team bakes a web server image that includes a WAF module, scan it and look for the component. Whether a scanner matches a proprietary module to this CVE depends on how the advisory data names it, so verify rather than assume.
• Vulnerability matching that includes KEV. Safeguard matches components against vulnerability databases including CISA KEV, and reachability analysis ranks what your code actually calls, so a newly exploited entry rises to the top of the list for the open source and image components you ship.
• Holding old versions back. Policies and gates evaluated in the platform can stop a build or image that still carries a version you have decided must not ship.
• Doing the fix work with approval. The Safeguard CLI assistant can edit code and run commands with your approval. For this incident that means updating the version pin in the Ansible role or Dockerfile that installs your WAF module, adding the evidence snapshot as a step before the upgrade, and running the version checks above across your fleet scripts. Its /permissions modes run from Ask to Strict, and safeguard exec runs the same work in CI. Autonomous remediation can open fix pull requests for open source dependencies; it is off by default.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. Neither SiteGuard Server Edition nor Siemens Software Center is an open source package in those ecosystems. SiteGuard's flaw was reported by its developer to IPA, and the Siemens flaw was reported by a Huntress researcher.

Gold Open Source (gold.safeguard.sh, free, no login) is searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, with a free read API and a CI gate GitHub Action. It is built around open source components. Do not assume it lists these proprietary products; for both, the vendor advisories and CISA KEV are the source of truth.

Gold Registry (registry.safeguard.sh, paid) provides hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages; an artifact loses its badge on regression. It does not ship SiteGuard or Siemens software, and we are not claiming a fixed build of either. The habit it supports is the one that applies to the open source parts of your stack: pull patched, signed components from a curated source and rebuild fast when a fix lands.

Common mistakes

• Patching SiteGuard before saving diagnostics. The vendor says the update may erase attack traces. Export the diagnostic information first.
• Reading 7.8 as "high, not critical, can wait". The vendor and JVN rate it urgent and critical, it is exploited, and CISA gave three days.
• Assuming a disabled statistics feature equals a fix. JPCERT/CC lists it as a workaround. Upgrade or apply the patch.
• Forgetting end of life installs. The vendor patch covers them. Old hosts on a forgotten contract are the most likely to be missed.
• Skipping the Siemens hunt because you do not use Siemens. The attackers ship the binary themselves.
• Blocking the Siemens executable by hash. It is genuine. You will break real installs and miss nothing the hunt would not catch by path and parent.
• Removing the scheduled task before stopping the process. In the related campaign Huntress saw persistence recreated while the implant ran. Stop the process first.
• Trusting a valid signature. A valid Authenticode signature on SiemensSoftwareCenter.exe is expected in both the clean and the malicious case.
• Treating "updated" as "clean". A Siemens Software Center copy that auto updated to 4.0.9.8 says nothing about whether a malicious copy ran from a user folder last week.

FAQ

Which versions fix CVE-2026-106931 in SiteGuard Server Edition?

Ver8.00 Update5 for the Apache httpd, Nginx and IIS editions, and Ver7.00 Update6 for the FreeBSD Apache and Nginx editions. Versions from Ver2.20 up to those builds are affected when the statistics feature is on, which is the default. IIS Ver3.10 through Ver4.00 Update4 are not affected. A file replacement patch is available for systems that cannot upgrade, including end of life versions.

Is SiteGuard being exploited?

Yes. The vendor, JVN and JPCERT/CC all state that exploitation has been confirmed, and CISA added it to KEV on 20 October. No public source describes the attackers, targets, scale or indicators.

Why does the CVSS vector say local access if this is a web server module?

The vector models an attacker who already has low privileged local access. Public sources do not explain how attackers obtained that in the wild. The score describes preconditions, while the exploitation, the root or SYSTEM impact and CISA's three day deadline describe urgency.

What should I collect before updating SiteGuard?

The vendor asks for the Diagnostic Information export from the web admin console, under Diagnostic Information, then Download Diagnostic Information. Add a host snapshot (processes, sockets, scheduled jobs, recent logins and recently changed files) and copy everything off the host.

Which version of Siemens Software Center fixes CVE-2026-110936?

Version 4.0.9.8 or later. Siemens says existing installs update automatically on next start. The version observed in the attacks was 3.5.8.7, which Siemens described as the latest at the time.

Was Siemens hacked?

Siemens says no Siemens system, product or update channel was breached to its knowledge. Attackers distributed a genuine signed copy of the program alongside malicious DLLs, outside official channels, in a bundle named AllMyBasic.msi.

I do not use Siemens software. Can this still affect me?

Yes. The attack carries its own copy of the vulnerable program. Any Windows user who runs the installer, typically after following a ClickFix lure, can end up with it in a per user programs folder. Run the hunt in step 5.

Can I just block SiemensSoftwareCenter.exe?

Not by hash or signature without breaking legitimate installs. Block or alert on the context instead: the executable running from AppData\Local\Programs, launched by msiexec, with unexpected DLLs beside it.

How is this related to the ChatGPT custom GPT ClickFix campaign?

Siemens links its case to ROMULUS. Forescout documented ROMULUS delivering a Stardock side loading package that Huntress had seen in its custom GPT campaign, and the IP Siemens lists for distributing AllMyBasic.msi also appears in Forescout's ROMULUS indicators. That shows shared delivery infrastructure. It does not prove the Siemens payload is the same RAT.

Does Safeguard detect these attacks?

No. It helps with the inventory, policy and fix work for the software and images you build, and its CLI can carry out remediation steps with your approval.

Fix it without waiting for upstream

For SiteGuard and Siemens Software Center, the fix has to come from the vendor, and both vendors have shipped one. The section below is about the larger share of software most teams carry: the open source dependencies and container images you build and ship, where the same gaps apply.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

The CLI demo is a real session fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json, and runs install and tests with approval. For SiteGuard, you would use the same loop on your infrastructure repository: ask it to add the diagnostic and host snapshot step before the upgrade task, bump the pinned module version to Ver8.00 Update5, and run the version check, approving each command. The demo does not show this incident.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on your computer, a folder choice, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. Here, the folder would be the repository that holds your Windows hunting scripts, and the edits would be adding the Siemens indicators and the path based checks from step 5, each one reviewed before it runs.

Click through it at your own pace, or open it full screen.

The mobile demo is a real Android session: work goes to a computer running the CLI and you approve the command on the phone with Allow once, Allow for turn or Deny. With a three day federal deadline on SiteGuard, this is how an on call engineer would approve the evidence export and the upgrade command without waiting to get back to a laptop.

Click through it at your own pace, or open it full screen.

To scan the images and dependencies you build and run, download Safeguard and follow the CLI docs.

Quick check

Sources

• EG Secure Solutions: SiteGuard Server Edition OS command injection vulnerability (alert-202610-1)
• JVN#88474777: SiteGuard Server Edition vulnerable to OS command injection
• JPCERT/CC: JPCERT-AT-2026-0032
• CVE-2026-106931 record (CVE Services API)
• Siemens ProductCERT: SSA-580366, DLL sideloading vulnerability in Siemens Software Center
• Siemens ProductCERT: Active exploitation of CVE-2026-110936 in Siemens Software Center
• CVE-2026-110936 record (CVE Services API)
• CISA KEV catalog entry: CVE-2026-106931
• CISA KEV catalog entry: CVE-2026-110936
• CISA: BOD 26-04 implementation guidance
• Forescout Vedere Labs: ROMULUS, analysis of a new multi payload ClickFix delivery platform
• Huntress: Attackers abuse ChatGPT custom GPTs to deliver RAT via ClickFix
• SecurityWeek: Siemens Software Center vulnerability exploited in ClickFix malware attacks
• The Hacker News: CISA orders federal agencies to patch exploited Plex2Shell, Siemens and SiteGuard flaws
• BleepingComputer: Hackers exploit SiteGuard WAF flaw to run commands as SYSTEM, root
• Impress INTERNET Watch: SiteGuard Server Edition vulnerability report (Japanese)
• Help Net Security: Malicious ChatGPT custom GPT lures users into installing a RAT

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.