Mandiant and Digital Knowledge disclosed CVE-2026-5426 on May 26 after responding to a late-2025 intrusion at a customer running KnowledgeDeliver, a Japanese-market ASP.NET learning management system with deep penetration across the country’s universities and corporate training programs. The bug is the same shape that has burned dozens of .NET products over the last three years: a hardcoded <machineKey> element shipped in the vendor’s stock web.config, identical across every customer install built from the standard package. Anyone who pulled a copy of the config from one tenant — a former employee, a leaked GitHub repo, a misconfigured backup — could forge a signed __VIEWSTATE payload that any other internet-facing KnowledgeDeliver server would deserialize and execute. CVSS 7.5; rated high because exploitation is unauthenticated, network-reachable, and requires no user interaction.

The bug

ASP.NET Web Forms uses __VIEWSTATE to round-trip server-side control state through the browser. The framework signs (and optionally encrypts) the blob with the keys configured in <machineKey> so that the server can trust what the client sends back. The original design assumed every deployment would generate its own random keys — IsolateApps, AutoGenerate — and for fifteen years the security community has been screaming at vendors not to ship constant keys in distributed web.config files. Digital Knowledge did anyway. Every KnowledgeDeliver installation built before February 24, 2026 used a single vendor-supplied validationKey / decryptionKey pair, baked into the stock configuration handed to customers at deployment time.

Once an attacker has those two hex strings, the exploit chain is ysoserial.net boilerplate. Generate a TypeConfuseDelegate or ActivitySurrogateSelector gadget, sign the payload with the leaked keys, send it as the __VIEWSTATE form field to any handler that processes ViewState, and the IIS worker process (w3wp.exe) deserializes the gadget chain into a running cmd.exe. There is no patch you can write for a leaked key — the only fix is to rotate it, which is exactly what Digital Knowledge’s February hotfix did by switching to per-deployment keys generated at install time.

What the attackers did with it

Mandiant’s investigation traces the activity back to late 2025 at a single Japanese institutional victim and then watched it bloom into broader exploitation through Q1 and Q2 2026. The initial payload was BLUEBEAM, also known publicly as the Godzilla web shell — but loaded entirely in memory inside the w3wp.exe process rather than dropped to disk. No file artifacts, no IIS handler registration, just a long-running thread inside the worker process listening for AES-encrypted commands on the same TCP port the LMS already listens on. Forensically the only signal is anomalous TLS traffic and the worker process behaving like a C2 client.

From the BLUEBEAM foothold the operators staged Cobalt Strike Beacon for lateral movement and modified a frontend JavaScript bundle served by the LMS to prompt visiting users to install a “security authentication plugin.” The fake installer dropped a second Cobalt Strike beacon onto the endpoint of anyone who fell for it — a watering-hole leg of the campaign that turned every compromised LMS into a launcher for client-side compromise of its student and admin populations. The TTPs — BLUEBEAM, in-memory web shells, Cobalt Strike, watering-hole pivots on the served JavaScript — align with several Chinese-speaking clusters Mandiant has tracked previously, including APT41 and UNC215, though neither has been definitively attributed.

Who is exposed

Digital Knowledge does not publish a customer list, but KnowledgeDeliver has been a default LMS choice for Japanese universities and large enterprises for over a decade. Public Shodan and Censys queries on the IIS server header strings and KnowledgeDeliver-specific URI paths return a few thousand internet-facing instances clustered almost entirely in .jp IP space. Every instance built from a vendor package dated before 2026-02-24 shares the leaked keys with every other instance built from the same package. Air-gapped or internal-only deployments are not in the immediate cross-hairs but are still vulnerable to any insider or third-party with web.config read access.

Mitigation

Patch to the latest KnowledgeDeliver build, which generates per-deployment machine keys at install. If you cannot redeploy immediately, manually replace the validationKey and decryptionKey values in <system.web><machineKey> with freshly generated 64-byte random values and restart the application pool — that single change kills the universally-shared-key exposure without waiting for a vendor rebuild. Hunt retrospectively for __VIEWSTATE POSTs with payloads larger than 2 KB to LMS endpoints, for anomalous outbound TLS connections from w3wp.exe, and for modifications to JavaScript bundles served by the LMS within the last six months. Mandiant’s writeup includes BLUEBEAM YARA rules and Cobalt Strike configuration IOCs from the observed clusters.

Takeaway

This is the seventh major hardcoded-machineKey RCE in a commercial .NET product in eighteen months. The pattern is mature, the exploitation is commoditized, and the mitigation has been known since the Microsoft guidance was written in 2009. If your vendor still ships a stock web.config with a fixed <machineKey>, you are running a service whose authentication boundary is whatever GitHub search returns for that key value.

References

  • Mandiant / Google Cloud Threat Intelligence — Exploitation of KnowledgeDeliver via ViewState Deserialization Vulnerability
  • The Hacker News — KnowledgeDeliver LMS Flaw Exploited to Deploy Godzilla and Cobalt Strike
  • BleepingComputer — KnowledgeDeliver flaw exploited as a zero-day to install web shells
  • SecurityWeek — Hackers Exploited KnowledgeDeliver Zero-Day for Web Shell Deployment
  • Digital Knowledge advisory — KnowledgeDeliver security update notice (2026-02-24)