CVE-2026-5426: Mandiant Catches ViewState RCE Against KnowledgeDeliver LMS in Japan

Executive Summary

Mandiant has disclosed CVE-2026-5426, an ASP.NET ViewState deserialisation vulnerability in KnowledgeDeliver, a popular learning-management system from Digital Knowledge widely deployed across Japan. The root cause is the textbook one for this class of bug: every pre-February-24-2026 deployment of KnowledgeDeliver shipped with identical hardcoded machineKey values in web.config. Once an attacker recovered the shared key from any single instance (or from a leaked image, vendor archive, or co-tenanted hosting), they could forge cryptographically valid __VIEWSTATE payloads against every other deployment in the world.

Mandiant observed the bug being exploited in the wild against at least one Japanese customer in late 2025, with a coherent post-exploitation chain: an in-memory BLUEBEAM web shell (Godzilla family, running entirely inside w3wp.exe); ACL widening of the web root with icacls; JavaScript tampering on the LMS’s own static files to bait staff and students into running a fake “security authentication plugin” that pulled remote attacker code; and finally a customised Cobalt Strike BEACON whose payload was encrypted with a key derived from the victim’s organisation name. The primary on-host signal is Application Event ID 1316 with sub-event code 4009, which fires whenever ASP.NET fails ViewState validation; Mandiant recovered decrypted BLUEBEAM strings out of those event-log entries during the IR.

The vulnerability

ASP.NET WebForms applications serialise client-side state into the __VIEWSTATE POST parameter, sign it (and optionally encrypt it) with values from <machineKey>, and deserialise it on the next request. If the validation MAC checks out, the framework happily deserialises whatever .NET object graph the attacker put inside — including the standard ysoserial.net-style gadget chains that pivot deserialisation into command execution. The whole attack class lives or dies on whether the attacker knows machineKey.

Digital Knowledge’s mistake was shipping the same machineKey to every customer. Schematically, every vulnerable web.config looked like:

<machineKey decryptionKey="<REDACTED>" validationKey="<REDACTED>" />

Once that single secret pair was known — from any vendor distribution, any compromised box, any leaked image — every other KnowledgeDeliver installation was a one-shot ViewState RCE. This is the same failure mode Microsoft itself documented in February 2025 (“Code Injection Attacks Using Publicly Disclosed ASP.NET Machine Keys”) and the same pattern Mandiant covered in its prior Sitecore ViewState Deserialization Zero-Day piece. The vendor pushed a fix on February 24, 2026 — but because the underlying problem is a leaked secret, the patch alone is not enough: every operator must rotate to a unique machineKey per instance.

Post-exploitation activity

BLUEBEAM web shell deployment

The first payload landed by the ViewState chain was BLUEBEAM, Mandiant’s name for a .NET in-memory web shell in the Godzilla family. It runs entirely inside the IIS worker process (w3wp.exe), with command traffic carried in encrypted HTTP POST bodies. Because it never lands on disk in the usual sense, traditional file-system scanning misses it; the on-host evidence is in process trees and in IIS request logs that look like ordinary POSTs to a legitimate page. The one persisted artefact Mandiant observed across cases is:

File tampering

With code execution inside the LMS’s worker process, the attacker widened ACLs on the web root using icacls, granting Everyone full access. They then modified the LMS’s shipped JavaScript so that, on next page load, students and staff saw a fake security prompt urging them to install a “security authentication plugin.” The same modified JS quietly loaded a second remote script from attacker infrastructure — the bridge into the next stage of the chain.

Cobalt Strike infection

Users who fell for the fake plugin downloaded an installer that decrypted and ran a Cobalt Strike BEACON. The payload was encrypted with a custom key derived from the victim organisation’s own name — suggesting per-target preparation rather than spray-and-pray. By that point the attacker had pivoted from a single server compromise to interactive C2 on operator endpoints inside the customer network.

How to hunt for this activity

Application Event Log, ID 1316

ASP.NET writes a Windows Application Event Log entry — Event ID 1316 — whenever ViewState validation fails. Two sub-event codes matter:

Event code: 4009-++-Viewstate verification failed. Reason: The viewstate supplied failed integrity check.
Event code: 4009-++-Viewstate verification failed. Reason: Viewstate was invalid.

The first — integrity-check failure — is what you see when an attacker is throwing payloads at the endpoint with an incorrect key. Routine, but rare in non-public-facing apps. The second — “Viewstate was invalid” — is what you see when the MAC did validate (so the attacker knows the key) but the resulting object graph failed to deserialise cleanly into the expected ASP.NET state machine. That second case is the “exploitation succeeded” signal. During the Mandiant IR, decrypted BLUEBEAM strings were recovered directly out of those event-log entries.

Suspicious process activity from w3wp.exe

Mandiant’s SecOps content keys off the IIS worker process spawning unusual children. Two example queries from the source (reproduced verbatim):

(metadata.log_type = "WINEVTLOG" or metadata.log_type = "WINEVTLOG_XML") 
metadata.product_event_type = "1316"
additional.fields["Message"] = /Event code: 4009\b/ nocase

(metadata.event_type = "PROCESS_LAUNCH" or metadata.event_type = "PROCESS_OPEN") AND
principal.process.command_line = /w3wp.exe/ nocase AND
target.process.command_line = /cmd.+ \/c |whoami|powershell/ nocase

The point is the same either way: w3wp.exe launching cmd /c, whoami, or PowerShell is overwhelmingly malicious in production. Legitimate web applications almost never need to fork a shell.

File integrity monitoring

Watch for unauthorised changes to .js, .aspx, and .config files under the LMS web root, particularly insertions of remote <script> loaders or unfamiliar JavaScript blobs at the top of otherwise vendor-stable files.

Anomalous user-agent strings

The attacker’s traffic shows a recognisable mistake: two distinct browser identifiers concatenated into a single User-Agent header. The three concrete examples Mandiant published (verbatim):

Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.2 (KHTML, like Gecko) Chrome/22.0.1216.0 Safari/537.2 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101213 Opera/9.80 (Windows NT 6.1; U; zh-tw) Presto/2.7.62 Version/11.01 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36

Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) chromeframe/10.0.648.205 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36

The same UA-doubling pattern appeared in Mandiant’s previous Sitecore ViewState write-up — likely the same tooling.

Remediation and mitigation

• Rotate the machineKey immediately, even after applying the Digital Knowledge fix. A patch cannot revoke a secret that has already leaked; only key rotation invalidates the attacker’s ability to forge ViewState payloads.
• Generate per-instance, cryptographically strong keys — not a single shared key reused across a fleet, which only recreates the original problem.
• Restrict network exposure of the LMS to known organisational IP ranges where the business model allows.
• Conduct a full IR sweep on every pre-Feb-24-2026 deployment, with particular attention to Application Event ID 1316 history, w3wp.exe child processes, and JavaScript drift in the LMS web root.

Indicators of Compromise

Key Takeaways

• CVE-2026-5426 is an ASP.NET ViewState deserialisation RCE in KnowledgeDeliver caused by identical hardcoded machineKey values across every customer deployment before February 24, 2026.
• Patching alone is insufficient: once the shared key is known, it has to be rotated everywhere. The Mandiant guidance is explicit about this.
• Post-exploitation chain: ViewState gadget → BLUEBEAM (Godzilla) in-memory web shell → icacls ACL widening → LMS JavaScript tampering → fake “security plugin” → Cobalt Strike BEACON encrypted with the victim’s organisation name.
• Primary detection is Windows Application Event ID 1316 with code 4009. The integrity-check-failed variant is reconnaissance; the “Viewstate was invalid” variant is post-key-knowledge exploitation.
• Process-tree signal: w3wp.exe spawning cmd /c, whoami, or PowerShell. This pattern is essentially zero-FP for an LMS box.
• UA doubling (two concatenated User-Agent strings in one header) is a consistent attacker tooling fingerprint shared with Mandiant’s prior Sitecore ViewState write-up.
• Same class of bug as Microsoft’s February 2025 advisory on publicly disclosed ASP.NET machine keys, and Mandiant’s prior Sitecore ViewState zero-day. The pattern keeps recurring because shipping software with a fixed machineKey — or with one that ends up in a public sample — converts “authenticated” ASP.NET sinks into unauthenticated RCE.

Defensive Recommendations

• If you run KnowledgeDeliver: confirm the Feb-24-2026 vendor patch is applied, rotate machineKey to a unique value, and then assume previous compromise — sweep for the IOC above and for Application Event ID 1316 history.
• If you run any ASP.NET application: audit your web.config for shipped/templated machineKey values, treat the key as a secret with the same handling as a TLS private key, and rotate after any incident touching the server.
• Alert on w3wp.exe → cmd /c / whoami / powershell. The published SecOps query above is a good starting point regardless of LMS.
• Alert on Application Event ID 1316, especially the “Viewstate was invalid” variant which signals key-aware exploitation.
• Detect JavaScript drift in vendor-stable web roots. A fake “security plugin” landing on staff browsers is one of the loudest available signals if you are watching the right file.
• For vendors shipping ASP.NET appliances: never ship a static machineKey. Generate per-install during first boot and store it where the customer can rotate it.
• For SOC content engineers: import Mandiant’s named SecOps rules (“IIS ViewState Exploitation Success,” “ASP.NET ViewState Deserialization Attempt,” “W3wp Launching Cmd With Recon Commands,” etc.) or build equivalents in your platform.

Conclusion

CVE-2026-5426 is the fourth ViewState-from-leaked-machineKey advisory of the last 15 months and unlikely to be the last. The class is depressingly resilient: it only needs the secret to leak once, anywhere, for every other deployment of the same product to become an unauthenticated RCE target. Mandiant’s write-up is worth reading in full both for the IR detail and for the hunting playbook — the Event ID 1316 / 4009 signal in particular is a cheap, high-precision detection that any defender running ASP.NET applications can stand up in an afternoon. For operators of KnowledgeDeliver specifically: patch, then rotate, then sweep, in that order.

This article is an independent English-language rewrite of “Exploitation of KnowledgeDeliver via ViewState Deserialization Vulnerability” by Takahiro Sugiyama, Peter Revelant, and Mathew Potaczek, originally published on the Google Cloud Threat Intelligence (Mandiant) blog on May 25, 2026. The vulnerability disclosure record is published as MNDT-2026-0009. All IOCs, hunting content, and IR findings remain the work of the original authors and Mandiant; please cite Mandiant when referencing this material.