SiteGuard WAF command injection CVE-2026-106931 exploited for root

Attackers are exploiting an OS command injection flaw in SiteGuard Server Edition, the host-based web application firewall from Japanese vendor EG Secure Solutions. CVE-2026-106931 lets an attacker run arbitrary commands as root or SYSTEM on the server running the WAF. The vendor disclosed the bug on October 14 and said abuse was already confirmed; JPCERT/CC issued urgent alert JPCERT-AT-2026-0032 the same day. The flaw scores 8.5 on CVSS v4.0 and 7.8 on v3.0.

What the bug does

The flaw sits in SiteGuard's statistics function, which is enabled by default on host-based instances. A request to that function can inject operating-system commands that execute with the privileges of the WAF process — root on Unix-like hosts, SYSTEM on Windows. Because SiteGuard Server Edition runs on the same box as the web server it protects, a compromise of the WAF is a compromise of the web server behind it.

Affected and fixed versions

• Affected: Ver2.20 and later, before the fixed releases below, across the Apache httpd, Nginx and IIS editions.
• Not affected: the IIS edition Ver3.10 through Ver4.00 Update 4.
• Fixed: Ver8.00 Update 5 (Apache httpd, Nginx and IIS, excluding FreeBSD) and Ver7.00 Update 6 (Apache httpd and Nginx on FreeBSD).

For installations that cannot move to a current release, EG Secure ships a patch that replaces the files used in statistics processing, including for end-of-life versions. Confirm your exact build against the vendor advisory and JPCERT/CC's alert before acting.

Exploitation status

The vendor states exploitation has already been observed but has not published attack details, victim counts, or an actor. JPCERT/CC's alert repeats the in-the-wild warning. There is no public proof-of-concept as of writing, and the CVE is not in CISA's KEV catalog. No IOCs, YARA or Sigma rules have been published by the vendor or JPCERT/CC — do not expect a detection signature yet.

The vendor notified customers with direct support contracts on September 29, roughly two weeks before the public October 14 disclosure. That gap means some exposed servers could have been attacked before most administrators heard of the flaw — treat any unpatched, internet-reachable instance as potentially already touched.

Action checklist

1. Update now to Ver8.00 Update 5 (Apache/Nginx/IIS) or Ver7.00 Update 6 (FreeBSD Apache/Nginx).
2. Before you patch or upgrade, download the diagnostic information from the web management console (Web management screen → Diagnostic information → Download). The vendor warns that remediation may erase attack traces, so capture it first if you need to investigate.
3. If you can't upgrade immediately, apply the vendor's file-replacement patch for the statistics processing, available down to end-of-life versions.
4. If an upgrade and the patch are both out of reach, disable the statistics function to remove the default exposure, and treat the host as suspect until you have reviewed it.
5. Hunt for compromise on any instance that was internet-reachable and unpatched since late September: unexpected processes or scheduled tasks running as root/SYSTEM, and modifications under the statistics component.

Context

A WAF is a security control that sits in front of the application precisely because it is exposed; a command-injection RCE in that control inverts its purpose, handing attackers the highest-privilege foothold on the host it was meant to defend. The pattern is familiar from the run of edge-security and perimeter-appliance bugs this year — flaws in the device that is supposed to be the gatekeeper. The detail worth watching here is the private-notice-to-public-disclosure gap: the vendor's own "abuse confirmed" language, paired with a two-week head start for attackers over the general user base, is why "patch today" is not hyperbole for this one.