SiteGuard Server Edition CVE-2026-106931: exploited command injection

CVE-2026-106931 sits in the software meant to protect the web server. SiteGuard Server Edition is a host-based web application firewall from the Japanese vendor EG Secure Solutions, installed into Apache httpd, Nginx or IIS. Its statistics feature, on by default, contains an OS command injection that lets an attacker run commands as root or SYSTEM, and the vendor says attackers are already using it.

EG Secure Solutions released the fixed versions and told customers with direct support contracts on 29 September 2026. The public advisory followed on 14 October, alongside JVN#88474777 and JPCERT/CC alert JPCERT-AT-2026-0032; JVN says the developer reported the flaw itself. JPCERT/CC says the product is widely used in Japan. CISA added the CVE to its Known Exploited Vulnerabilities catalog on 20 October, gave federal agencies until 23 October and marked forensic triage as required.

Who is affected

Every version from Ver2.20, released in April 2015, up to the fixed builds, when the statistics feature is on:

Ver7.00 Update 6 exists only for FreeBSD. Elsewhere, a server on the 7.00 line moves to Ver8.00 Update 5 or takes the patch described below. The advisories name only Server Edition; SiteGuard Proxy Edition, SiteGuard Cloud Edition and the SiteGuard WP Plugin for WordPress are not listed.

How it works

JVN describes SiteGuard Server Edition as a WAF "designed to be integrated into a web server". The flaw is classed as CWE-78, OS command injection: input reaches a system command without its special characters being neutralized, so part of it runs as a command of its own. The vendor places the bug in the statistics feature, and JVN says an attacker may run arbitrary OS commands "with root or SYSTEM privileges".

That is all the advisories say about the mechanism. They do not name the input, the component that builds the command or how an attacker reaches it. JPCERT/CC, the CVE numbering authority, scores the attack as local, needing low privileges and no user interaction: 7.8 in CVSS 3.0 and 8.5 in CVSS 4.0. Read literally, that describes someone who can already act on the server as an unprivileged user and uses the statistics feature to become root or SYSTEM. Neither advisory says how attackers got that first foothold, or whether another route exists.

The labels are stronger than the scores. EG Secure Solutions titles its advisory critical (緊急) and JVN marks it Critical, though both CVSS scores fall in the high band. CISA's SSVC assessment records exploitation as active, not automatable, with total technical impact.

Is it being exploited?

Yes. The vendor's Japanese advisory says exploitation has already been confirmed, and JPCERT/CC and JVN repeat it. CISA added the CVE to KEV on 20 October and lists ransomware use as unknown.

• Timeline. Ver8.00 Update 5 and Ver7.00 Update 6 were released on 29 September 2026, the day the vendor told support-contract customers. The public advisory came 15 days later, on 14 October, and was last modified on 16 October.
• Deadline. CISA's due date left federal agencies three days, and the entry requires a forensic triage under BOD 26-04: check whether the server was compromised, not only patch it. It was one of six additions that day, listed in our October KEV roundup.
• What is not public. The attacker, the victims, the number of servers, when exploitation began and how attackers reached the statistics feature. BleepingComputer notes that neither advisory gives these details, and the vendor, JPCERT/CC and CISA have published no indicators of compromise.

The vendor does not say whether it knew of attacks when it shipped the fix on 29 September; it says only that it told customers about the flaw and the fix that day. BleepingComputer's install figure comes from WordPress.org's count for the SiteGuard WP Plugin, a separate product the advisories do not list.

Check your exposure

First find every web server with SiteGuard Server Edition loaded. The advisories do not name module files or install paths, so search for the product name:

# Modules Apache has loaded
apachectl -M 2>/dev/null | grep -i siteguard
 
# The full nginx configuration as nginx reads it
nginx -T 2>/dev/null | grep -i siteguard
 
# Any web server configuration that mentions it
grep -ril siteguard /etc/httpd /etc/apache2 /etc/nginx /usr/local/etc 2>/dev/null

Import-Module WebAdministration
Get-WebGlobalModule | Where-Object { $_.Name -match 'siteguard' -or $_.Image -match 'siteguard' }

For each hit, check the edition and version against the table and whether the statistics feature is on. Anything from Ver2.20 below the fixed build, with statistics on, needs the fix. The vendor directs questions to its support desk or to JPCERT/CC.

Fix it

1. Save the evidence first. In the web management screen, open [Diagnostic information] and choose [Download diagnostic information]. The vendor warns that updating or patching may erase traces of an attack. Keep the file off the server.
2. Update. Install Ver8.00 Update 5 for Apache httpd, Nginx or IIS, or Ver7.00 Update 6 for Apache httpd or Nginx on FreeBSD. Installers are on the vendor's download page, which needs your customer login.
3. Or patch. If you cannot upgrade, the vendor provides a patch that replaces the files used for statistics processing, end-of-life versions included. Everything before Ver7.00 is already out of support, and several 7.00 builds, including IIS, reach end of support on 30 November 2026.
4. Confirm. Run the checks again and confirm every server runs a fixed build or carries the patch.

If you can do neither today, JPCERT/CC says disabling the statistics feature avoids the flaw. Neither JPCERT/CC nor the public vendor advisory gives the steps; JPCERT/CC points to the vendor. Turning the feature off tells you nothing about what happened before, so save the diagnostic information either way.

Detect attempts and compromise

No indicators have been published, so detection rests on preserved evidence and on the generic signs of a root or SYSTEM compromise. CISA's forensic triage guidance sets the order: collect evidence before you patch or contain, log what you collected, then decide whether a compromise occurred.

• Vendor evidence. The diagnostic information download is the only artifact the vendor names. The advisory does not describe its contents.
• Processes. Shells or scripting engines such as sh, bash, cmd.exe or powershell.exe started by the web server or SiteGuard components, especially as root or SYSTEM.
• Persistence. New accounts with root or administrator rights, unfamiliar SSH keys, cron jobs, scheduled tasks or services.
• Files. Recent changes to web server configuration, the web root or SiteGuard's own settings.
• Network. Outbound connections from the web server to hosts it has no reason to contact.

# Accounts with UID 0 and root's SSH keys
awk -F: '$3 == 0 {print $1}' /etc/passwd
ls -la /root/.ssh/ 2>/dev/null
 
# Scheduled jobs
ls -la /etc/cron* /var/spool/cron* /var/cron/tabs 2>/dev/null
 
# Files changed in the last 30 days under web server configuration and content (adjust paths)
find /etc/httpd /etc/apache2 /etc/nginx /usr/local/etc /var/www -type f -mtime -30 2>/dev/null

Get-LocalGroupMember -Group Administrators
Get-ScheduledTask | Select-Object TaskPath, TaskName, @{ n = 'Runs'; e = { $_.Actions.Execute } }
Get-CimInstance Win32_Service | Select-Object Name, StartName, PathName

Compare the output with a known-good baseline. If anything is unexplained, treat the server as compromised: root or SYSTEM on a web server reaches its TLS keys and application secrets, and the WAF meant to guard it. Rebuild from known-good media, rotate those secrets and follow your incident response process.

When the WAF is the way in

A host-based WAF runs inside the web server it protects, so a flaw in it can hand over the server itself, here as root or SYSTEM. Here the fix existed for 15 days before the public advisory, and customers without a direct support contract, including those on end-of-life builds, may have heard first on 14 October. Keep security agents on the same patch cadence as the servers they guard, and confirm the fix with evidence, not a version string; how a retest verifies a fix explains Rokkhe's approach for findings it has reproduced.