Organizations using SiteGuard Server Edition face an urgent patching and investigation task after exploitation was confirmed against a command-injection vulnerability in the web application firewall. The flaw, tracked as CVE-2026-106931, affects the product’s statistics-processing feature and can allow commands to run with the operating system’s highest privileges.

That combination makes the issue especially serious: SiteGuard is installed directly on the servers it protects, while its statistics function is enabled by default. A successful attacker could therefore turn limited local access into control as root on Unix-like systems or SYSTEM on Windows. EG Secure Solutions confirmed exploitation and alerted directly supported customers on September 29, 2026; Japanese coordination bodies subsequently published public warnings.

What the vulnerability allows

CVE-2026-106931 is classified as OS command injection, or CWE-78. Improper handling inside the statistics function permits crafted input to reach operating-system command processing. Because the affected service operates with elevated rights, injected commands do not remain confined to the attacker’s original permission level.

The issue carries a CVSS 4.0 score of 8.5 and a CVSS 3.0 score of 7.8. Those ratings describe a local attack requiring low privileges and no user interaction. Administrators should not misread the reports as evidence of an unauthenticated, internet-wide remote exploit. The confirmed risk is privilege escalation: an intruder who has already gained limited access may be able to convert that foothold into complete server control.

Public advisories do not identify the threat actors, their victims, the number of attacks, or the precise exploitation chain. That leaves defenders without a narrow indicator set and makes host-level review important. Affected organizations should look beyond the WAF itself for signs that an initial foothold preceded attempts to abuse the vulnerable component.

Versions and platforms requiring attention

Affected releases begin with SiteGuard Server Edition 2.20 when statistics are enabled. The correct fixed release depends on the platform:

• Apache, Nginx and IIS editions outside FreeBSD should move to version 8.00 Update 5.
• Apache or Nginx installations on FreeBSD should move to version 7.00 Update 6.
• Windows IIS editions from 3.10 through 4.00 Update 4 are an exception and are not affected.

Inventory should therefore capture both the installed version and whether statistics processing is active. Merely finding SiteGuard on a server is not enough to determine exposure, and a version-only scan can mishandle the Windows exception.

Preserve evidence before patching

The vendor offers replacement files for organizations that cannot perform a full upgrade, including users of releases that have reached end of support. However, remediation may erase diagnostic traces needed to establish whether exploitation occurred. Administrators should first open the web console’s “Diagnostic Information” area, download the available diagnostic package, and store it securely for investigation.

After evidence is preserved, teams should install the appropriate update or patch promptly. They should review privileged command execution, unexpected processes, changed files, new accounts and unusual outbound connections around the suspected window. Any server showing signs of compromise should be isolated while responders determine the initial access method and the scope of follow-on activity.

Why a WAF flaw demands a broader response

A security control running on production servers occupies a sensitive trust position. If an attacker can abuse that control to gain operating-system authority, the resulting access may expose application code, secrets, customer data and adjacent services. The WAF’s presence does not reduce the need for endpoint monitoring, least privilege and segmented administration.

With exploitation already acknowledged, this is not a wait-for-more-details situation. Defenders should preserve evidence, establish which systems meet the affected configuration, apply the correct fix, and investigate whether limited access was escalated before remediation. They should also document unaffected systems and the basis for that conclusion, giving incident leaders a reliable record for later review.