Attackers Are Exploiting a Root-Level Flaw in SiteGuard Server Edition, and Updating May Erase the Evidence

EG Secure Solutions, the Tokyo company that makes the SiteGuard web application firewall (WAF), said on Wednesday, October 14 that attackers are already exploiting an OS command injection flaw in SiteGuard Server Edition, the edition that installs as a module inside a web server. The flaw, CVE-2026-106931, sits in the product’s statistics feature, which is on by default. Japan Vulnerability Notes (JVN) says an attacker “may be able to execute arbitrary OS commands with root or SYSTEM privileges on the system running the affected product.”

The vendor also warns that updating or patching may erase the traces of an attack, and it asks customers to download the product’s diagnostic information before they change anything. BleepingComputer reported the flaw on Sunday, October 18. We read the primary documents behind that report, and several of the numbers in the coverage measure something other than affected servers.

Below: what the vendor, JVN and JPCERT/CC confirm, which versions are affected, what the “critical” label, the scores and two site counts really measure, what nobody has published, the fifteen days between the first customer notice and the public one, and what to do first.

What the vendor and Japan’s CERT confirm

Four documents carry the facts, and they agree with each other: the vendor’s urgent bulletin (in Japanese), the JVN entry JVN#88474777, JPCERT/CC’s alert JPCERT-AT-2026-0032 (in Japanese) and the NVD record. All four appeared on October 14. JPCERT/CC is Japan’s computer emergency response coordination center, and JVN is the vulnerability portal that JPCERT/CC provides together with IPA, Japan’s Information-technology Promotion Agency. JVN credits the vendor with reporting the flaw to IPA and says JPCERT/CC coordinated with the vendor under the Information Security Early Warning Partnership.

• What the product is. JVN: “SiteGuard Server Edition provided by EG Secure Solutions Inc. is a host-based Web Application Firewall (WAF) designed to be integrated into a web server.” The vendor’s product page describes a statistics and report feature that tallies attack detections and shows them as graphs on the management dashboard or exports them as a PDF report (our paraphrase). The notice does not describe the feature, but the names match.
• What the flaw is. OS command injection (CWE-78) in the statistics feature. “The product is affected by this vulnerability when the statistics feature is enabled. The feature is enabled by default.”
• That it is being exploited. “Note that the vulnerability has been confirmed to be exploited in the wild.” The vendor’s bulletin says abuse has already been confirmed, and JPCERT/CC’s alert relays that the vendor has confirmed it.
• The fix. Two fixed versions, listed below, and a stopgap: “For users who are unable to upgrade, the developer provides a patch that replaces the files used in statistical processing. The patch is available even for end-of-life (EOL) versions.”

IIS builds from Ver3.10 to Ver4.00 Update 4 are not affected. The notice lists only Server Edition as affected.

The “critical” label, the scores and two site counts

The coverage leans on four figures. Each one measures something narrower than it sounds.

The label and the scores. The vendor’s bulletin is marked urgent, JVN’s English page renders that as “Critical,” and BleepingComputer says the flaw “has critical severity.” That is the vendor’s label, not a score band. JPCERT/CC supplied the two scores NVD records, and NVD lists both as High: 8.5 under CVSS 4.0 and 7.8 under CVSS 3.0. Both vectors describe a local attacker who needs low privileges (AV:L and PR:L). We recomputed both scores from the vectors with the open-source cvss Python library and got the published numbers, then changed only the attack vector and the privileges required. With a network vector and no privileges, the same impact metrics score 9.8 under CVSS 3.0 and 9.3 under CVSS 4.0, both Critical. Changing either setting alone leaves the score in the High band (8.8 or 8.4 on 3.0, 8.7 or 8.6 on 4.0). That is our arithmetic, not a claim about this flaw. Our reading: the documents we read do not say how an attacker reaches the statistics feature or what access the attackers had, so the vector cannot tell you whether an outsider can get there, and a High score is no reason to treat the vendor’s confirmed-abuse warning as less urgent.

NVD and CISA. NVD published its record on October 14 and last changed it on October 16. Its status is Deferred, and the only scores on it are the two JPCERT/CC supplied. CISA’s Known Exploited Vulnerabilities (KEV) catalog, version 2026.10.16 with 1,748 entries, does not list the CVE, so tools that rank by KEV membership will not show it as exploited yet.

The site counts. The vendor’s home page claims deployments at 1.5 million or more sites and footnotes a market survey for the December 2023 period (our paraphrase). The SiteGuard series has three products, Cloud Edition, Server Edition and Proxy Edition, and the notice covers only Server Edition. BleepingComputer’s other figure, “Based on WordPress.org statistics, the product is active on 500,000 sites,” matches the 500,000+ active installs WordPress.org lists for the SiteGuard WP Plugin. That is a different product, a plugin that adds login and admin protections to WordPress, and the notice does not list it. Its description does mention a link to the WAF: “Creates exclusion rules to help prevent false positives when SiteGuard Server Edition WAF is installed.” Neither number counts vulnerable servers, and we found no published count of them. JPCERT/CC says only that it has confirmed the product is widely used in Japan.

What is not public

• Who and how many. BleepingComputer: “The attacker’s identity, the victims, the scale of the attacks, and the methods used remain unclear, as neither security advisory provides these details.”
• When it began. None of the documents we read says when exploitation started or when the vendor first confirmed it.
• The way in. The documents we read give no attack path, no proof of concept and no indicators of compromise. The vendor points to the product’s diagnostic information download as the way to preserve evidence and does not say what to look for in it.
• The install base. None of the documents we read counts Server Edition installs.
• Already updated? The vendor warns that the update may erase traces but gives no guidance for customers who updated before saving anything.

Fifteen days between the first notice and the public one

JVN says “The developer notified customers with direct support contracts of this vulnerability and the available countermeasures on September 29, 2026,” fifteen days before the public bulletin. Because none of the documents we read says when exploitation began, we cannot read those fifteen days as an exposure window. Our reading: a customer without a direct support contract was not covered by the September notice, and the bulletin’s own support instructions send customers to the contract confirmation sheet they received at delivery or to the reseller they bought through, which indicates that a reseller channel exists.

What to do first

1. Find out whether you run it. That means SiteGuard Server Edition for Apache, Nginx, IIS or FreeBSD, version 2.20 or later, with the statistics feature on. The WordPress plugin of the same name is a different product. If you run Server Edition on several web servers, check each one: the vendor’s product page describes settings distribution and consolidated reports across servers, and the notice does not say whether that changes exposure.
2. Save the diagnostic information before you change anything. In the management web screen, open Diagnostic information and choose Download diagnostic information. The vendor says an update or a patch may erase the attack traces. We would keep the copy off the server and also copy the web server and system logs, which the documents do not mention; those two points are our suggestions.
3. Update or patch. Ver8.00 Update 5 or Ver7.00 Update 6, or the vendor’s file-replacement patch for versions you cannot upgrade, including end-of-life ones.
4. If neither is possible yet, ask about the workaround. JPCERT/CC’s alert says disabling the statistics feature avoids the flaw and sends readers to the vendor for the steps. The vendor bulletin and the JVN entry we read list only the update and the patch, and we did not find the steps, so confirm with your support desk before relying on it. We have not tested it.
5. Investigate as well as patch. JPCERT/CC’s alert asks users to consider a compromise investigation along with the fix. The product is installed inside the web server, so root or SYSTEM on that host reaches whatever it holds. If anything suggests abuse, treat the private keys, credentials and tokens on that host as exposed (our suggestion). If you already updated before saving anything, ask the vendor what remains.
6. Ask your reseller. If you bought through one, ask whether the September 29 notice reached you. JPCERT/CC also asks anyone with information about the case to contact it.

Preserving evidence before patching is the order Mandiant recommended for the BeyondTrust Remote Support zero-day, where it also said an upgrade does not remediate earlier exposure (our BeyondTrust post), and the order CISA’s forensic-triage guidance asks of federal agencies for the flaw in our Ivanti Connect Secure post.

Sources and method

The vendor’s bulletin and product pages, JPCERT/CC’s alert and the Japanese press are in Japanese, so statements attributed to them are our paraphrase, which we read against the original text; they are not quotations. English quotations come from JVN and BleepingComputer, and the plugin description from the WordPress.org plugin API. Two Japanese outlets, Internet Watch on October 14 and ScanNetSecurity on October 16, relayed the same facts and added no detail on the attacks. The NVD record, the KEV catalog (from CISA’s JSON feed) and the WordPress.org plugin data (version 1.8.9, 500,000 active installs) were read again on Sunday, October 18 at 19:18 UTC. The weekdays, the fifteen-day gap and the what-if scores are our arithmetic. We did not run SiteGuard, did not test any exploit and did not scan for exposed servers, and the vendor’s pages may change after we read them. Times are UTC.