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.

What is affected

The flaw is in the statistics feature, and JVN notes the product is affected "when the statistics feature is enabled", which is the default.

Affected: SiteGuard Server Edition Ver2.20 and later. 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.

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.