Exploit · Breaking

SiteGuard Server Edition, a host WAF JPCERT says is widely used in Japan, has an exploited bug that runs commands as root. Save diagnostics before you patch

The WAF is the way in. EG Secure Solutions says attackers are already exploiting CVE-2026-106931, an OS command injection in the statistics feature of SiteGuard Server Edition, its host-based web application firewall. The feature is on by default, and a successful attacker runs commands as root or SYSTEM on the web server. One catch: the update can erase the evidence, so grab the diagnostics bundle first.

Oct 14, 2026 · 3 min read

EG Secure Solutions published an urgent advisory for CVE-2026-106931 on Oct 14, and JPCERT/CC followed the same day with alert JPCERT-AT-2026-0032. The bug is an OS command injection (CWE-78) in SiteGuard Server Edition’s statistics feature. The vendor confirms it has been exploited in the wild. JPCERT says the product is widely used in Japan and asks operators to look for compromise as well as patch. Victim count: Undisclosed. Actor: Undisclosed. How the attacks were delivered: Undisclosed.

What the product is. SiteGuard Server Edition isn’t a network appliance. It’s a WAF module that runs inside the web server itself, on Apache httpd, Nginx or IIS. That’s why a bug in it lands with the web server’s highest privileges. Per JVN, the impact is arbitrary OS commands as root or SYSTEM on the host running the product.

Why the score undersells it. EG Secure scores it CVSS 4.0 8.5 and CVSS 3.0 7.8, both with a local vector and low privileges (AV:L/PR:L). So an attacker needs some foothold on the box first. On a web server, that foothold usually comes from the application the WAF is there to protect: a webshell, an upload bug, or a compromised low-privilege service account. Chain any of those with this bug and you get root. The control you bought to reduce web app risk becomes the privilege escalation path.

Who is exposed. Ver2.20 and later with the statistics feature enabled, which is the default. On Apache, Nginx and IIS, that means anything before Ver8.00 Update5. On FreeBSD (Apache and Nginx), anything before Ver7.00 Update6. IIS builds Ver3.10 through Ver4.00 Update4 are not affected. It is not in CISA’s KEV catalog as of the Oct 14 catalog version.

The fix, and the trap. Upgrade to Ver8.00 Update5, or Ver7.00 Update6 on FreeBSD. If you can’t upgrade, EG Secure has a patch that swaps out the files the statistics process uses, and it covers end-of-support versions too. JPCERT says turning off the statistics feature avoids the bug entirely. The trap: EG Secure warns that applying the update or the patch can wipe the attack traces. Before you touch it, open the SiteGuard web console, go to Diagnostic information, download the bundle, and keep it somewhere off the box.

What we’d do this afternoon. Inventory every web server running SiteGuard, including ones a hosting provider or reseller set up for you. EG Secure notified customers with direct support contracts on Sep 29, so anyone who bought it another way may only be learning about it now. On each box, collect diagnostics, then patch, or disable statistics if the change window isn’t today. Treat any server that was exposed as possibly compromised until you’ve checked: look for shells or interpreters spawned by the web server or SiteGuard processes, new root or SYSTEM scheduled tasks and services, unknown files in web roots, and new local accounts or SSH keys. Then chase the original foothold. This bug only gets an attacker to root after something else let them in.

Sources