KnowledgeDeliver CVE-2026-5426: Mandiant traces RCE to shared ASP.NET keys

Mandiant published a post-mortem on May 26, 2026 linking an in-the-wild zero-day in Digital Knowledge's KnowledgeDeliver — an LMS heavily used by Japanese universities and corporate training departments — to identical, pre-shared ASP.NET machineKey values baked into multiple customer deployments. Anyone holding one valid key can craft a __VIEWSTATE payload the server will obligingly deserialize, yielding unauthenticated remote code execution on every instance that shares the same secret. The flaw is tracked as CVE-2026-5426 (CVSS 7.5).

The primary write-up is on the Google Cloud / Mandiant threat-intel blog; the vendor advisory chain runs through Digital Knowledge directly.

What the bug actually is

ASP.NET's ViewState mechanism signs and optionally encrypts request state with secrets held in the <machineKey> element of web.config. The contract is straightforward: if you control the keys, you control deserialization, and ASP.NET will instantiate any type the payload names. That is a textbook unauthenticated RCE primitive — and the open-source ysoserial.net automates payload generation against it.

Mandiant's finding is not "ViewState is dangerous" — it's that KnowledgeDeliver shipped the same validationKey and decryptionKey across independent customer installs. A single leaked key opens every box that still runs an unpatched build. That is, structurally, the same failure pattern Microsoft warned about in February 2025 when it published an advisory on attackers using publicly-disclosed ASP.NET machineKey values from code samples to drop the Godzilla web shell — itself a precursor of the chain Mandiant just observed against KnowledgeDeliver.

Affected versions

Per Mandiant and the vendor advisory:

• All KnowledgeDeliver deployments prior to February 24, 2026 are vulnerable.
• Digital Knowledge has shipped a patched build that generates a unique key on installation, and pushed a hardening notice to existing customers asking them to rotate to operator-generated keys rather than rely on the patched defaults.

The deployment base is overwhelmingly Japanese, but KnowledgeDeliver is sold internationally and a long tail of Japanese-curriculum sites exists outside .jp.

Exploitation status

Mandiant detected the activity during incident response work in late 2025 and worked the disclosure into early 2026. Observed exploitation involves:

• A crafted __VIEWSTATE POST that drops the BLUEBEAM web shell (also tracked as Godzilla) into the IIS worker process w3wp.exe. BLUEBEAM is in-memory only and communicates over encrypted HTTP POSTs — no on-disk artifact to scan for.
• Subsequent stages installing Cobalt Strike Beacon and a "fake plugin" download that lures KnowledgeDeliver users into running the loader.

Mandiant attributes the TTP set — BLUEBEAM/Godzilla + Cobalt Strike on an ASP.NET ViewState foothold — to Chinese-speaking activity historically overlapping with APT41 and UNC215, with the explicit caveat that the same TTPs are also used by financially motivated crews. No formal cluster assignment has been published.

Action checklist

1. Inventory KnowledgeDeliver hosts. Treat every install built or upgraded before February 24, 2026 as compromise-suspect until logs prove otherwise.
2. Patch — and then rotate keys anyway. The patched build no longer ships shared keys, but operators that simply upgraded without regenerating already-leaked machineKey material remain exposed. Replace validationKey and decryptionKey with cryptographically random values per instance.
3. Hunt in the IIS logs. Per Mandiant: look for Windows Application Log Event ID 1316 (ViewState verification failures), unexpected w3wp.exe spawning cmd.exe or powershell.exe, unauthorized changes to .aspx, .js, or .config files, and anomalous user-agents on POSTs carrying long __VIEWSTATE parameters. These signals are listed verbatim in the Mandiant write-up; we have not seen YARA or Sigma rules published yet.
4. Block egress from the IIS service account. BLUEBEAM's value to an attacker collapses if w3wp.exe cannot reach the internet directly.
5. Rotate KnowledgeDeliver admin and integration credentials, including SAML signing material and any service accounts whose tokens may have been minted from a compromised host.

Context

This is the third major hard-coded-key advisory of the year: Sitecore in December, Telerik's long-tail re-disclosure in March, and now KnowledgeDeliver. The pattern is identical — vendors that shipped "demo" or "default" cryptographic material that customers were expected to replace, but in practice rarely did, until the keys leaked and ViewState/JWT/SAML deserialization gave everyone the same skeleton key.

If you operate any .NET application that you did not generate <machineKey> material for yourself, treat that as a finding regardless of vendor. The KnowledgeDeliver case is unusual only because Mandiant did the work of telling the world about it.