SiteGuard: preserve evidence before patching an exploited WAF flaw

SiteGuard Server Edition runs on the web server it protects. Its statistics function has an OS command-injection flaw, CVE-2026-106931. EG Secure Solutions reports that the vulnerability has been exploited. JVN scores it 8.5 under CVSS 4.0, with a local attack vector and low privileges required. Successful exploitation may execute commands as root or SYSTEM on the server.

CISA added the CVE to its Known Exploited Vulnerabilities catalogue on 20 October 2026. The catalogue strengthens the prioritisation signal; it is not evidence that a specific CUP reader's server was compromised.

That access vector matters. A public website or WAF installation is not, by itself, proof of an unauthenticated remote path to this flaw. Equally, the local and low-privilege prerequisites do not make it harmless if an attacker already has a foothold on the host. The public notices do not disclose how the observed attackers obtained that prerequisite.

Establish the exposure boundary

The affected condition is SiteGuard Server Edition version 2.20 or later with statistics enabled, which is the default. The edition and release branch matter: Apache, Nginx and IIS builds before version 8.00 Update 5 are in scope; FreeBSD Apache and Nginx builds before version 7.00 Update 6 are in scope. JVN explicitly excludes IIS versions 3.10 through 4.00 Update 4. Check the running build and the actual statistics setting on each host, rather than classify a deployment from its product name alone.

The trust boundary is on the web server itself. A low-privileged local context interacting with the affected statistics processing may cross into root or SYSTEM command execution. This is an interpretation of the published vulnerability and CVSS vector, not a disclosed reconstruction of the attacks. Inventory should therefore connect the WAF edition and configuration to the host, its administrative access and the incident record.

Preserve evidence before changing the product

The unusual operational constraint is explicit in the vendor and JPCERT/CC notices: an update or patch may remove traces of an attack. They recommend obtaining SiteGuard's “Diagnostic Information” through its web management screen before the change. Preserve that bundle and relevant host evidence with the collection time, asset identity and access controls. A later clean scan of a fixed build cannot establish whether that host was compromised before remediation.

This is a short, bounded collection step, not a reason to leave an exploited system unpatched indefinitely. The incident owner should coordinate preservation with the web service owner, assess suspicious activity, then deploy the fix under change control. Where a production web service has availability constraints, record the permitted maintenance window, a rollback route and how the service will be checked afterward.

Fix the right branch, then test the effective state

For Apache, Nginx and IIS, the fixed release is version 8.00 Update 5. For FreeBSD Apache and Nginx, it is version 7.00 Update 6. The vendor also provides a patch replacing the statistics-processing file for installations that cannot upgrade. JPCERT/CC lists disabling statistics as a workaround; any such temporary configuration change needs vendor instructions and verification on the running host. A workaround does not investigate possible earlier compromise.

After remediation, verify the installed build or patch, statistics state, application availability and the retained diagnostic record. If the investigation finds signs of privileged misuse, handle recovery and credential review as incident decisions rather than close the case solely because the WAF now reports a fixed version.

Revisit this analysis if the vendor or JPCERT/CC changes the affected range, workaround or incident guidance. The confirmed exploitation does not justify claims about the number of victims, a specific initial-access technique or OT process effects.