Vulnerabilities

SiteGuard WAF flaw: save the evidence before you patch

By Yaali. October 20, 2026, 5 min read, Vulnerabilities, Patching, Threat intel.

CVE-2026-106931 in SiteGuard Server Edition gives root or SYSTEM and is exploited. Fixed versions, and why diagnostics come before the update.

EG Secure Solutions has confirmed that attackers are exploiting CVE-2026-106931, an OS command injection flaw in SiteGuard Server Edition. SiteGuard Server Edition is a host-based web application firewall (WAF): it installs on the web server itself as a module for Apache httpd, Nginx or IIS, and it is widely used in Japan. The flaw sits in the statistics feature, which is on by default, and it lets an attacker run commands as root on Linux and FreeBSD or as SYSTEM on Windows. It scores 8.5 under CVSS 4.0 and 7.8 under CVSS 3.0. JPCERT/CC, Japan's national computer emergency response team, issued an urgent alert on October 14, 2026.

If you run SiteGuard Server Edition Ver2.20 or later with statistics enabled, you are affected unless you are already on Ver8.00 Update 5 (Apache, Nginx, IIS) or Ver7.00 Update 6 (the FreeBSD builds). The one exception is the IIS edition from Ver3.10 to Ver4.00 Update 4, which is not affected. The order of work matters here: the vendor warns that updating or patching can erase traces of an attack, so download the diagnostic information from the admin console first.

How it works

The statistics feature summarises the WAF's activity, and the files that do that processing run on the server with the highest privileges available: injected commands come out as root or SYSTEM. The flaw is classed as CWE-78, improper neutralisation of special elements in an OS command. Somewhere in the statistics processing, input reaches an operating system command without being cleaned, so an attacker who can shape that input can append commands of their own.

Neither the vendor nor JVN, the Japanese vulnerability database run by JPCERT/CC and IPA, has published which input is injected. The CVSS 3.0 vector (AV:L/AC:L/PR:L/UI:N) does tell you the conditions. Attack vector local means the attacker needs to be on the server already. Privileges required low means any ordinary account will do, with no user interaction and low complexity.

Our reading of that vector, which the advisories do not spell out: this is a privilege escalation step. An attacker who gets a foothold as an unprivileged user, for example the web server's own account through a vulnerable application or a web shell, can turn it into full control of the host. On a machine whose whole job is to protect a web application, that foothold is the scenario the product exists for, and the WAF itself becomes the way up to root.

What attackers are doing

The vendor states that exploitation has been confirmed, and JVN and JPCERT/CC repeat that. No one has published who is behind the attacks, how many servers were hit, or what the attackers did after reaching root or SYSTEM.

The timeline matters for anyone who bought SiteGuard through a reseller. EG Secure Solutions privately alerted customers with direct support contracts on September 29, 2026. The public advisory, the JVN entry (JVN#88474777) and the JPCERT/CC alert (JPCERT-AT-2026-0032) all followed on October 14. Organisations outside the direct support channel therefore had about two weeks less warning, during a period when the flaw was already being used.

Some English-language summaries list a "Ver3.10" fix. The vendor advisory does not: Ver3.10 to Ver4.00 Update 4 is the unaffected IIS range, not a patched release.

What to do

Find every install. Check the version in the SiteGuard web admin console on each web server. Include staging and secondary servers, since the WAF is on every host it protects.
Save the diagnostic information before you change anything. In the web admin console, open the 診断情報 (Diagnostic Information) menu and choose 診断情報をダウンロード (Download Diagnostic Information). Store the file off the server, with the date and host name. The vendor and JPCERT/CC both say the update or patch may delete attack traces, and this file is what your support desk or an investigator will ask for.
Update. Apache, Nginx and IIS editions go to Ver8.00 Update 5 or later. FreeBSD Apache and Nginx editions go to Ver7.00 Update 6 or later.
If you cannot update yet, ask the vendor support desk or your reseller for the patch that replaces the file used for statistics processing. It is available for end-of-support versions too, so an old version is not a reason to stay exposed. Since the flaw needs the statistics feature enabled, ask support for the steps to turn it off as a stopgap; the public advisory does not give them.

The vendor has not published indicators of compromise, so the check below is general. Because exploitation gives root or SYSTEM, look for the persistence a privileged attacker would add, from late September onwards:

On Linux and FreeBSD: new accounts in /etc/passwd, changes to /etc/sudoers, new entries in root's crontab and /etc/cron.*, new systemd units or rc scripts, and unfamiliar keys in /root/.ssh/authorized_keys.
On Windows: Security log event 4720 (account created), 4732 (member added to a local group such as Administrators) and 4698 (scheduled task created), and System log event 7045 (service installed).
On both: web shells or recently changed scripts in the web root, since the attacker needed a local foothold first.

If you find any of these, treat the server as compromised. Rebuild it on a fixed SiteGuard version, rotate every credential stored on it (database passwords in application configs, TLS private keys, API keys), and hand the saved diagnostic file to the vendor or JPCERT/CC.

Patch runbooks should start with evidence

Most patch procedures go straight from "fix released" to "install it". For a flaw that is already being exploited, that order can destroy the only record of whether you were hit. A short step at the start of the runbook, such as a snapshot of the VM, a copy of product logs, or a vendor diagnostic bundle like SiteGuard's, takes minutes and keeps the investigation possible. Security products deserve this most, because they run with high privileges on the hosts they protect and are rarely watched as closely as the applications behind them.

We test web servers and the applications on them in our web penetration testing work, including what an attacker can reach after the first foothold, and our safeguarding and hardening service covers patch and evidence procedures like the one above. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: EG Secure Solutions advisory, JPCERT/CC alert JPCERT-AT-2026-0032, JVN iPedia JVNDB-2026-000148, JVN#88474777, Security Affairs, GBHackers, ScanNetSecurity, eSecurity Planet.