Attackers are exploiting CVE-2026-106931, an OS command injection flaw in SiteGuard Server Edition that can run commands with root privileges on Linux and FreeBSD systems or SYSTEM privileges on Windows.
Patching is only part of the response. EG Secure Solutions warns that updating or applying its patch may erase attack traces, so affected organizations should save SiteGuard diagnostic information before making remediation changes.
The vulnerability sits in SiteGuard Server Edition's statistics function, which is enabled by default. According to Japan Vulnerability Notes, successful exploitation can execute arbitrary OS commands with the privileges of the affected host.
Who is affected by CVE-2026-106931?
SiteGuard Server Edition is a host-based web application firewall (WAF) that integrates with a web server instead of running only as a separate network appliance.
CVE-2026-106931 affects SiteGuard Server Edition version 2.20 and later when the statistics function is enabled. The exact vulnerable ranges depend on the platform:
- Apache httpd, Nginx, and IIS: Versions 2.20 and later before 8.00 Update 5.
- Apache httpd and Nginx on FreeBSD: Versions 2.20 and later before 7.00 Update 6.
- IIS versions 3.10 through 4.00 Update 4: Not affected.
The statistics feature is enabled by default, so administrators shouldn't assume an installation is safe because nobody intentionally turned the feature on.
The flaw is classified as CWE-78 OS command injection. Its CVSS 4.0 base score is 8.5, or High, while its CVSS 3.0 score is 7.8. The CVSS score alone isn't the deciding factor here because the vendor has already confirmed exploitation in the wild.
One point needs careful handling: the public advisories don't describe an unauthenticated remote exploit.
The official CVSS vector lists the attack vector as local, requires low privileges, and requires no user interaction. Neither EG Secure Solutions nor JPCERT/CC has disclosed how attackers are obtaining that initial access, what payloads they're using, or which organizations have been compromised.
That leaves the exploit chain unknown. Security teams shouldn't assume the vulnerability can be triggered directly from the public internet, but they also shouldn't wait for more technical detail before addressing systems that match the affected configurations.
Save diagnostic evidence before applying the fix
The unusual part of the response is the order.
In its security bulletin, EG Secure Solutions says updating or patching SiteGuard may remove evidence of an attack. Before remediation, administrators should use the web management interface to download and retain Diagnostic information:
Web management screen > Diagnostic information > Download diagnostic information
Keep that bundle somewhere separate from the affected server. If compromise is suspected, it should become part of the organization's normal digital forensics and incident-response evidence rather than being left only on the system being investigated.
After preserving the diagnostics, organizations have three supported options:
- Update Apache, Nginx, or IIS installations to 8.00 Update 5 or later.
- Update FreeBSD Apache or Nginx installations to 7.00 Update 6 or later.
- Apply the vendor's standalone patch if a full upgrade isn't possible. EG Secure Solutions says the patch is available for end-of-life versions as well.
For environments that can't update or patch immediately, JPCERT/CC says disabling the statistics function prevents exposure to this vulnerability. That should be treated as an interim workaround rather than a reason to leave a vulnerable build in place indefinitely.
JPCERT/CC also recommends considering a compromise investigation on affected systems because exploitation has already been observed.
What security teams should do now
A practical response doesn't require waiting for exploit code or more reporting about the attackers.
Start with an inventory of SiteGuard Server Edition systems, then:
- Check the installed version and platform.
- Confirm whether the statistics function is enabled.
- Download and preserve Diagnostic information before changing the installation.
- Investigate affected systems for signs of compromise.
- Upgrade to the fixed release or apply the vendor patch.
- Disable statistics as a temporary workaround if immediate remediation isn't possible.
- Recheck systems after remediation to confirm they're running a fixed version.
EG Secure Solutions says customers with direct support contracts were notified about the vulnerability and countermeasures on Sept. 29, while the public advisory arrived Oct. 14. The vendor hasn't disclosed when exploitation began, who is behind it, or how many systems have been compromised.
Those unknowns don't change the immediate response. The statistics function is enabled by default, exploitation is confirmed, and remediation itself can remove useful evidence. Preserve the diagnostics first, then close the vulnerable path.
Also read: GitLab recently patched a server-takeover vulnerability carrying a CVSS 10.0 score.