SiteGuard's statistics feature runs attacker commands as root

A command-injection bug in the statistics function of SiteGuard Server Edition lets an attacker run OS commands as root or SYSTEM on the host, and it is already being used. The flaw is tracked as CVE-2026-106931, rated critical by the vendor and by Japan’s JPCERT/CC, and the statistics feature that carries it is enabled by default on host-based installs.

SiteGuard is a Japanese WAF vendor. It says its products protect more than 1.5 million websites; WordPress.org’s statistics put the product around 500,000 active sites. A WAF sits in front of the application to catch exactly this class of input, so a command injection in the WAF’s own code gives an attacker execution on the box that was meant to be the chokepoint.

Details on who is doing it are thin. SiteGuard’s bulletin and JPCERT/CC both confirm active exploitation (“Abuse has already been confirmed,” per the vendor), but neither names the attacker, the victims, the scale, or the request that triggers it.

Affected versions

• SiteGuard Server Edition for Apache httpd, Nginx, and IIS (excluding FreeBSD): versions 2.20 and later, before 8.00 Update 5.
• SiteGuard Server Edition for Apache httpd and Nginx on FreeBSD: versions 2.20 and later, before 7.00 Update 6.

Exploitation is possible on those versions when the statistics function is active, which is the default state. IIS editions 3.10 through 4.00 Update 4 inclusive are not affected, per JPCERT/CC.

What to do

Upgrade to 8.00 Update 5, or 7.00 Update 6 on FreeBSD. For installs that cannot move versions, the vendor offers a patch that replaces the files used in statistics processing, and it covers end-of-life releases.

Preserve evidence before you touch anything. The vendor warns that updating or patching can erase attacker traces along with the vulnerable code, because the fix overwrites the same statistics files an attacker would have hit. Pull the diagnostic bundle first (Web management screen -> Diagnostic information -> Download diagnostic information) and keep it off the box. If an unknown party has had root-level execution, you want that capture before the remediation rewrites the files they used.

One timeline detail affects how you scope exposure: customers with direct support contracts were notified on September 29, ahead of the public bulletin. If you run SiteGuard through a reseller or without a support contract, assume your window of exposure predates the advisory you are reading now, and treat the host as potentially already compromised rather than merely vulnerable.