JVN has published CVE-2026-106931, an OS command injection in SiteGuard Server Edition, a host-based web application firewall from EG Secure Solutions. The advisory is blunt about status: "Note that the vulnerability has been confirmed to be exploited in the wild."

Two things in the primary documents did not survive into the coverage, and both change what you should do.

Patch second. Collect the evidence first

JPCERT/CC alert at260032, published on 14 October, carries an instruction that reverses the usual order of operations. The vendor reports that a completed update may delete the traces of compromise. So the guidance is to obtain the diagnostic information from the SiteGuard web management console, preserve any attack traces, and only then apply the update.

Read that again, because it is rare. The normal advice after an exploited flaw is to patch immediately and investigate afterwards. Here, patching immediately destroys the data the investigation needs.

That puts administrators in a real bind rather than a theoretical one: every minute spent collecting diagnostics is a minute the hole stays open, and every minute saved by patching first is evidence gone. The vendor has picked a side, and the reason it can is that the attacker already needs a foothold.

Which brings us to the second thing.

The vector says local

Headlines have this as attackers running commands as root or SYSTEM, which is accurate and incomplete. JVN scores it 7.8 High on CVSS v3 with the vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, and 8.5 High on CVSS v4.

AV:L is local. PR:L is low privileges required. In JVN's own scoring, this is not an unauthenticated attacker reaching your web application firewall across the internet. It is someone who already has some access on the box turning that into root or SYSTEM.

That does not make it less serious. A web application firewall runs in front of the thing it protects, usually with privileges to match, and an attacker who gets root there owns the traffic as well as the host. But it does change the shape of the response. If the vector is local, the question is not only "is my WAF exposed" but "who already has a low-privileged account on that server, and what else did they do".

It also explains the evidence instruction. If an attacker needed a foothold first, the traces of how they got that foothold are the most valuable thing on the machine, and they are what the update may remove.

The feature is on by default

The flaw is in the statistics feature, and JVN says the product is affected "when the statistics feature is enabled", which is how it ships. The question is not whether somebody switched it on. It is whether anybody ever switched it off. Affected builds run from Ver2.20 onward, and the fix is Update 5 of version 8, or Update 6 of version 7 on FreeBSD.

In full: SiteGuard Server Edition Ver2.20 and later is affected, fixed in Ver8.00 Update 5 for the Apache httpd, Nginx and IIS editions and Ver7.00 Update 6 for Apache httpd and Nginx on FreeBSD. The IIS editions Ver3.10 through Ver4.00 Update 4 are not affected.

For anyone who cannot upgrade, the vendor supplies a patch that replaces the files used in statistical processing, and JVN records that "The patch is available even for end-of-life (EOL) versions" — which is a better outcome than most end-of-life software gets.

One more detail from the reporting rather than the advisories: support-contract customers were told privately on 29 September, and the public disclosure came on 14 October. Two weeks in which the people who knew were the people who paid.

CISA listed it on 20 October

CISA added CVE-2026-106931 to its Known Exploited Vulnerabilities catalogue on 20 October, filed as an OS command injection in SiteGuard Server Edition from EG Secure Solutions. The due date for federal civilian agencies is 23 October — three days, which is as short as CISA sets. Known ransomware use is recorded as unknown.

That deadline lands awkwardly against the vendor's own instruction. An agency now has three days to apply an update that the vendor says may delete the traces of compromise, and the catalogue does not sequence the two. The required action under Binding Operational Directive 26-04 does point at CISA's forensics triage requirements, but that wording appears on every entry rather than having been written for this one.

The listing does not say where the exploitation is happening. CISA's threshold is reliable evidence of active exploitation, not evidence of victims inside its own constituency, so the entry confirms what JVN already said rather than extending it.

What to do

  • Collect diagnostic information from the SiteGuard management console before you update, and store it somewhere the update cannot touch. This is the vendor's own order.
  • Then update to Ver8.00 Update 5, or Ver7.00 Update 6 on FreeBSD, or apply the replacement-file patch if you are on a version that cannot move.
  • Treat the box as potentially compromised rather than merely vulnerable. The flaw is confirmed exploited and the vector implies the attacker was already inside.
  • Audit low-privileged accounts and local access on any host running this, because that is what the vector requires.
  • If the statistics feature is not something you use, check whether it is on. It is by default.

What is not established

  • Who is exploiting it, how many systems, or by what method. None of that has been disclosed.
  • Whether exploitation predates the 29 September private notice.
  • How an attacker typically obtains the local foothold the vector requires. The advisories describe the escalation, not the entry.
  • Whether the two-week gap between private and public disclosure had any effect on exploitation either way.
  • The precise diagnostic procedure. JPCERT points to the vendor's own guidance rather than reproducing it, and the vendor advisory is Japanese-only.