EG Secure Solutions and JPCERT/CC have confirmed in-the-wild exploitation of CVE-2026-106931, an OS command injection in the SiteGuard Server Edition web application firewall. The flaw sits in the statistics feature, which is on by default, and lets an attacker run commands as root or SYSTEM on the server the WAF protects.
What happened
JVN published advisory JVN#88474777 on October 14, 2026, the same day as the vendor's Japanese-language security alert. JVN rates the bug Critical. It is classed as CWE-78 and scored CVSS v4.0 8.5 and CVSS v3.0 7.8. Both vectors are local with low privileges required (AV:L/PR:L). Neither advisory explains how attackers reached the statistics feature in the observed attacks, and neither names the attacker or the number of victims. The vendor notified customers with support contracts on September 29, 2026, about two weeks before public disclosure.
Affected and fixed versions, per JVN and BleepingComputer:
| Edition | Affected | Fixed |
|---|---|---|
| Apache httpd, Nginx, IIS | Ver 2.20 through 8.00 Update 4 | Ver 8.00 Update 5 |
| Apache httpd and Nginx on FreeBSD | Ver 2.20 through 7.00 Update 5 | Ver 7.00 Update 6 |
IIS builds 3.10 through 4.00 Update 4 are not affected. A server is only vulnerable when the statistics feature is enabled. The fix has two options: update to a fixed version or, if you cannot upgrade, apply the vendor's patch that replaces the statistics processing files, which covers end-of-life versions too. BleepingComputer reports that SiteGuard protects about 1.5 million websites.
The vendor also says to download diagnostic information before patching, because applying the update may erase traces of an attack.
Why it matters
SiteGuard Server Edition is a host-based WAF, so it runs on the same web server as the application it protects. A root or SYSTEM foothold there reaches everything on that host: application config files, database connection strings, TLS private keys, API tokens, and any service account credentials the site uses. The WAF is often treated as a trusted security control and left out of hunting scope, which is exactly why a compromise there can sit unnoticed.
The identity angle is indirect but real. Once the host is compromised, every secret stored on it should be treated as exposed. Patching closes the hole but does not take back credentials that have already been read.
This fits the pattern from recent weeks of attackers going after the security and edge products themselves. A similar recent case is the Cisco Secure Email Gateway zero-day.
What to check in your environment
- Inventory every SiteGuard Server Edition install, including web servers run by hosting providers or vendors for you. Record the edition (Apache, Nginx, IIS, FreeBSD) and the exact version and update level.
- Confirm whether the statistics feature is enabled on each install. It is on by default, so assume yes until you've checked.
- Before patching, download SiteGuard's diagnostic information from every affected host and keep it, as the vendor advises. Keep web server and OS logs from the same period.
- Upgrade to 8.00 Update 5 (Apache/Nginx/IIS) or 7.00 Update 6 (FreeBSD). If you can't upgrade, including on end-of-life installs, get the patch that replaces the statistics processing files from the vendor.
- Check whether your support contact received the September 29 vendor notice. If it did and nothing was done, treat the gap between September 29 and your patch date as an exposure window.
- On affected hosts, look for unexpected processes, accounts, scheduled tasks or files. Neither advisory says when exploitation began, so don't limit the review to recent weeks. If you find signs of compromise, rotate the secrets stored on that host: database credentials, application API keys, service account passwords and TLS keys.