CVE-2026-5426: KnowledgeDeliver installations deployed before Feb. 24, 2026 relied on a standardized web.config that contained identical ASP.NET machineKey values, creating a single secret that enabled unauthenticated remote code execution across multiple customer sites.
CVE-2026-5426 and the shared machineKey failure
Mandiant's investigation into a late‑2025 compromise of a KnowledgeDeliver Learning Management System (LMS) identified a critical root cause: a vendor-supplied web.config containing hardcoded, identical ASP.NET machineKey values across customer deployments. The relevant configuration line in affected installs looked like this: <machineKey decryptionKey="" validationKey="" />. Because the same keys were used everywhere, an actor who recovered the key from one instance could craft ViewState payloads that other KnowledgeDeliver servers would accept and deserialize. Mandiant tracked the issue as CVE-2026-5426.
How the ViewState deserialization was weaponized
The attack abused ASP.NET ViewState. When an application uses a known machineKey, an attacker can craft a malicious ViewState payload and deliver it in the __VIEWSTATE parameter of an HTTP request. If the server accepts the ViewState—signing and integrity checks pass—the server will deserialize the payload, allowing code execution. Mandiant linked this technique to previous ViewState deserialization patterns and to published cases of code injection when machine keys are publicly disclosed.
Post-exploitation: BLUEBEAM web shell, file tampering, and tailored Cobalt Strike
Once the actor gained code execution, Mandiant observed a sequence of follow-on actions focused on persistence, lateral impact, and user infection. The actor deployed an in‑memory .NET web shell known as BLUEBEAM (also known as Godzilla) that runs inside the IIS worker process (w3wp.exe) and accepts encrypted command payloads via HTTP POST bodies. Because BLUEBEAM operates entirely in memory, it evades file‑based scanning.
The actor also modified the web application filesystem. Commands were observed that changed permissions—using icacls to grant “Everyone” full access to the web application directory—and that altered application JavaScript to:
- display a fake security alert prompting users to install a “security authentication plugin,” and
- silently load a remote malicious script hosted on a threat actor–controlled domain.
That remote script persuaded users to download a fake installer that ultimately installed a Cobalt Strike BEACON backdoor on workstations. Mandiant noted the BEACON payload was encrypted using a key incorporating the compromised organization’s name, indicating a tailored payload prepared for that target.
How defenders can hunt: logs, processes, files, and User‑Agent strings
Mandiant published concrete hunting indicators and detection points. Key items to monitor include:
- Windows Application Event Log (Event ID 1316) from the ASP.NET source (for example, ASP.NET 4.0.30319.0). Watch for Event code: 4009 messages with reasons such as “The viewstate supplied failed integrity check” (failed attempt) or “Viewstate was invalid” (indicating deserialization was attempted and may have succeeded). Mandiant decrypted payload strings recorded in event log messages using the server’s machine keys and recovered a BLUEBEAM‑related payload.
- Suspicious child processes of w3wp.exe. Observed commands included invocations of cmd.exe /c ... whoami and powershell.exe.
- File integrity alerts for unexpected changes to .js, .aspx, or .config files in the web root—particularly the addition of remote script loaders or unusual logic.
- Anomalous User‑Agent strings. Mandiant identified concatenated identifiers and provided examples such as: “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.2 (KHTML, like Gecko) Chrome/22.0.1216.0 Safari/537.2” and “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36.”
Remediation required: rotate machine keys and restrict access
Mandiant’s primary remediation recommendation is immediate rotation of the machineKey: “Immediately generate a unique, cryptographically strong machine key for each KnowledgeDeliver instance.” Because the shared machineKey was the enabling failure, generating unique keys is the only way to invalidate the shared secret across impacted deployments. Additional mitigations noted include restricting access to the LMS to known organizational IP ranges where feasible, and conducting a thorough investigation if any exploitation indicators are present.
What this means for technologists, procurement leaders, and end users
Technologists and security teams should prioritize key rotation, hunt for the published indicators (Event ID 1316 / Event code: 4009, w3wp.exe child processes, web root file changes, and anomalous User‑Agent strings), and inspect Application event logs for decrypted payload traces where possible. Procurement and operations teams should examine deployment templates and vendor-supplied configuration artifacts to ensure no reusable secrets are distributed across customers. End users of affected LMS instances should be wary of in‑browser prompts to install “security authentication” plugins and report unexpected prompts to IT, since the actor used malicious JavaScript and remote scripts to deliver a fake installer that led to a tailored Cobalt Strike BEACON infection.
The KnowledgeDeliver compromise underlines a simple technical truth: one shared secret can become a universal key to many doors. Generating unique cryptographic keys per deployment and instrumenting the IIS and application stack for the specific indicators above are immediate steps that will blunt this class of attack.
