KnowledgeDeliver Zero-Day CVE-2026-5426 Dropped Godzilla Web Shell and Cobalt Strike
Google's Threat Intelligence Group caught attackers exploiting CVE-2026-5426, a hardcoded ASP.NET machineKey in Digital Knowledge's KnowledgeDeliver LMS, to forge ViewState payloads, drop the Godzilla web shell, and stage Cobalt Strike Beacon. The patch alone is not enough.
CVE-2026-5426 is not a configuration bug — it is a build-time cryptographic defect that ships the same secret to every customer, and the patch is not the end of the response. Rotating the key is.
TOKYO — On May 25, 2026, Google's Threat Intelligence Group disclosed that attackers had exploited CVE-2026-5426, a high-severity vulnerability in Digital Knowledge's KnowledgeDeliver Learning Management System, as a zero-day to deploy the Godzilla web shell and then Cobalt Strike Beacon on victim networks. The flaw, scored CVSS 7.5, stems from hardcoded ASP.NET `machineKey` values baked into KnowledgeDeliver's configuration file — a defect that enables ViewState deserialization attacks leading to remote code execution. With a stable `machineKey` known to the attacker, ViewState payloads can be forged against any vulnerable instance, bypassing the integrity check ASP.NET relies on. Google's Threat Intelligence Group, which incorporates Mandiant, observed the activity during incident-response engagements. Digital Knowledge has released a patch.
KnowledgeDeliver is widely deployed in Japan, where it is one of the more common LMS platforms used by universities, corporate training programs, and government training programs. The activity was reported by The Hacker News and SecurityWeek alongside Google's Threat Intelligence Group disclosure. No public reporting attributes the campaign to a named threat actor.
What Happened
Google's Threat Intelligence Group, the unit that incorporates Mandiant, disclosed CVE-2026-5426 after catching it being used. The disclosure describes a zero-day vulnerability in Digital Knowledge's KnowledgeDeliver — a Learning Management System widely deployed in Japan across universities, corporate training programs, and government training programs — exploited in the wild and surfaced during Mandiant's own incident-response engagements. The flaw carries a CVSS score of 7.5. Digital Knowledge has released a patch, and the activity was reported by The Hacker News and SecurityWeek alongside the Google's Threat Intelligence Group disclosure.
The technical chain reported across all three sources is consistent. The attacker, holding the hardcoded ASP.NET `machineKey` value extracted from a KnowledgeDeliver configuration file, forges a malicious ASP.NET ViewState payload that passes ASP.NET's cryptographic integrity check because the attacker holds the same key the server uses to validate. Submitting the forged payload to a vulnerable KnowledgeDeliver instance triggers deserialization and remote code execution. The attacker then deploys the Godzilla web shell for persistent access and, from that foothold, deploys Cobalt Strike Beacon — the post-exploitation framework that has become the de facto staging tool for hands-on-keyboard intrusion operations. Google's Threat Intelligence Group has not named the threat actor behind the activity, identified the victim organizations, or stated how many KnowledgeDeliver deployments were compromised.
A Hardcoded `machineKey` Is a Build-Time Defect, Not a Configuration Mistake
The single most important fact about CVE-2026-5426 is the class of defect it represents. The ASP.NET `machineKey` is the cryptographic secret an ASP.NET application uses to sign and encrypt the ViewState — the encoded blob the framework round-trips between server and client to preserve page state. When the key is unique per instance and properly secured, ViewState integrity holds: a tampered payload fails the signature check and is rejected. When the key is hardcoded into the application's default configuration and ships with every customer install, the integrity check collapses for everyone the moment any one customer's copy is extracted. That is the situation with KnowledgeDeliver. The `machineKey` value lives in a configuration file shipped with the product, and every instance of KnowledgeDeliver — across every customer — uses the same one. An attacker who pulled the value from any one deployment, or from a leaked installer, or from a piece of decompiled binary, holds a master key against every other deployment. This is not a customer misconfiguration that a hardening guide can address. It is a build-time defect in how the product was packaged, and it can only be remediated by Digital Knowledge changing how the product ships and by every customer rotating their key after patching.
Forged ViewState → Godzilla → Cobalt Strike: The Classic Web-Shell-to-Beacon Chain
What the attacker did with the forged `machineKey` is the part most defenders will recognize. Step one is the ViewState payload itself: with a key the server will accept, the attacker constructs a serialized .NET object designed to execute attacker-controlled code when ASP.NET deserializes it. Step two, on successful exploitation, is the Godzilla web shell — an open-source web shell, originally developed in China and widely available, that has become a frequent appearance in incident-response investigations of compromised internet-facing ASP.NET applications. Godzilla provides the attacker with a persistent foothold and a basic command-and-control channel for follow-on actions. Step three is the Cobalt Strike Beacon, the commercial adversary-simulation framework whose cracked versions have become the staple post-exploitation tool of organized intrusion operators. From Beacon, the attacker has full hands-on-keyboard tooling — credential dumping, lateral movement, kerberoasting, and the rest of the post-exploitation kit. This is a textbook web-shell-to-Beacon staging sequence, and the implication for incident response is that a confirmed exploitation of CVE-2026-5426 should be scoped as a full intrusion, not a single-host clean-up.
ASP.NET ViewState RCEs Have a Long Lineage — and KnowledgeDeliver Joins It
CVE-2026-5426 is the latest entry in a defect class that has been hitting enterprise ASP.NET applications for years. ViewState deserialization remote code execution, driven by leaked, default, or hardcoded `machineKey` values, has broken Microsoft Exchange, Microsoft SharePoint, and a long line of smaller ASP.NET-based products. The pattern is consistent enough that it has become a permanent fixture of any ASP.NET threat model: if the integrity-protection key is recoverable, the deserialization is exploitable. KnowledgeDeliver is the same story on a less-watched platform. It lands the same week as another ASP.NET deserialization flaw patched in Microsoft SharePoint, and follows the actively-exploited Microsoft Exchange Server zero-day CVE-2026-42897 disclosed earlier in May. On-premises ASP.NET servers are a sustained attack surface, and the back-office applications running on them — LMS platforms, HR systems, expense and ticketing portals — receive far less defensive attention than the tier-one Microsoft server estate. They deserve the same scrutiny.
Scope and Impact
The reason CVE-2026-5426 deserves more attention than its 7.5 CVSS score will earn it is the structural nature of the underlying defect. A hardcoded `machineKey` does not just create a vulnerability — it creates a vulnerability that the vendor's patch cannot fully close on its own. The patch presumably hardens the deserialization path or changes how the key is generated and stored, but it cannot retroactively un-publish the value that has been shipping in production for however long. If the original key is in the hands of an attacker — and the disclosure makes clear it is, because that is how the exploitation worked — then every deployment that has not rotated its key is still forgeable, patched or not. The remediation is therefore two distinct actions, both required: apply the patch, and rotate the `machineKey` so the value the attacker holds no longer matches the value the server validates against.
Several specifics remain unconfirmed and should not be assumed. Google's Threat Intelligence Group has not named the threat actor behind the activity, identified the victim organizations, or stated how many KnowledgeDeliver deployments were compromised. The exact patched version and release date, and whether the patched version of KnowledgeDeliver also rotates the previously-hardcoded `machineKey` automatically or merely changes the code path, have not been specified in public reporting. Whether other Digital Knowledge products, or other LMS or ASP.NET applications, ship with the same defect is also unaddressed. Godzilla's historical China-nexus associations are context, not attribution: the tool is open-source, widely shared, and has been used by multiple unrelated operators. The activity here should be treated as unattributed until evidence links it to a named group. The flaw lands in the same crowded week as the SharePoint deserialization disclosure and follows the exploited Exchange Server zero-day disclosed earlier in May — see the Verizon 2026 Data Breach Investigations Report finding that vulnerability exploitation just overtook credential theft as the number-one initial-access method for the broader context this fits into.
The pattern is consistent enough that any organization running on-premises ASP.NET applications should treat it as a category, not an isolated incident. The Iran-linked Screening Serpens APT, which abused AppDomainManager hijacking to load remote access trojans into legitimate .NET processes, and the Apache HTTP/2 double-free RCE patched in six days, are recent examples that .NET-runtime and web-server attack surface remains a live and well-resourced target. Defenders should not treat KnowledgeDeliver as an outlier because it is a smaller-market product; the defect class is industry-wide, and the attacker tooling is identical.
Response and Attribution
For KnowledgeDeliver customers, the action is sequential and both steps are required. First, apply Digital Knowledge's patch for CVE-2026-5426 immediately on every instance. Second, rotate the `machineKey` value on every KnowledgeDeliver instance — generate a unique, strong machineKey per deployment, replace the shipped value, and confirm the change has taken effect. Patching the deserialization path is necessary but not sufficient while the original hardcoded key remains in place: if the attacker holds that key, they can still forge ViewState payloads against any deployment that has not rotated. Treat any internet-accessible KnowledgeDeliver instance that was unpatched between disclosure and remediation as assume-breach until cleared. Audit hosts running KnowledgeDeliver for the Godzilla web shell, unexpected .aspx files in application directories, anomalous IIS worker-process (w3wp.exe) child processes, and Cobalt Strike Beacon indicators including known Beacon network patterns and the staging behaviors typical of hands-on-keyboard operators.
For SOC and threat-hunting teams, the hunt has two parts. The first is for the exploitation itself: ViewState deserialization signatures in IIS logs — abnormally large or malformed `__VIEWSTATE` parameters, ViewStates that decrypt successfully when the request shouldn't have a valid one, and unusual `__EVENTVALIDATION` patterns paired with anomalous request methods. The second is for the follow-on payloads: add Godzilla web-shell indicators and Cobalt Strike Beacon indicators to detection feeds, and proactively scan the environment's ASP.NET applications, regardless of vendor, for default, shared, or leaked `machineKey` values. The latter sweep is the more valuable long-term action because it generalizes beyond KnowledgeDeliver. For application-security and platform-engineering teams, the takeaway is that no ASP.NET application should ship with a hardcoded `machineKey` or any cryptographic secret in its default configuration; the key must be generated per-instance at install or first-boot. Ask vendors of ASP.NET-based applications whether each customer instance receives a unique `machineKey` and request documentation of the generation mechanism.
On attribution, the honest position is that there is none. Google's Threat Intelligence Group has not named the actor behind the activity, and the presence of Godzilla — a tool with historical China-nexus associations but wide availability and use by multiple unrelated operators — should be treated as context, not as attribution. For CISOs, CVE-2026-5426 is a reminder that the long lineage of ASP.NET `machineKey` and ViewState remote-code-execution flaws that has hit Microsoft Exchange Server, Microsoft SharePoint, and others is a well-understood and entirely preventable defect class — and that LMS, HR, expense, and other back-office ASP.NET applications deserve the same scrutiny as the tier-one Microsoft-server estate. The web-shell-to-Cobalt-Strike progression is the standard hands-on-keyboard intrusion staging sequence; a confirmed CVE-2026-5426 exploitation should be scoped as a full intrusion investigation, not a single-host event.
The CyberSignal Analysis
Signal 01 — The Patch Is Necessary but Not Sufficient — Rotate the `machineKey`
Most coverage of CVE-2026-5426 will frame it as a patch story: a vulnerability disclosed, a vendor fix released, customers apply the update, the chapter closes. That framing is incomplete in a way that matters operationally. The defect here is not a code path that the patch closes — it is a cryptographic secret that the patch cannot un-publish. If the original hardcoded `machineKey` has been recovered by attackers, which the exploitation itself demonstrates, then every deployment that has not rotated its key is still cryptographically forgeable, regardless of patch status. Customers who patch and move on are not done with this vulnerability; they are running a patched server with an attacker-controlled signing key. The complete remediation is patch plus rotate, and the order matters: rotate after the patch is in place, so the new key is generated by the patched code path. Brief operations teams that the after-patch step exists; brief CISOs that 'we patched' is not the same as 'we remediated' for this defect class.
Signal 02 — Back-Office ASP.NET Is the Soft Underbelly
The defect class behind CVE-2026-5426 — hardcoded or leaked `machineKey` values driving ViewState deserialization remote code execution — has been hitting enterprise ASP.NET applications for years. Microsoft Exchange and Microsoft SharePoint are the famous victims, and their high-profile vulnerabilities receive the security industry's full attention: vendor security teams, threat intelligence reporting, KEV listings, and federal patch deadlines. KnowledgeDeliver, an LMS used heavily in Japan, sits in a far quieter corner of the same attack surface. The same defect class, the same exploitation primitive, the same downstream tooling — and a fraction of the defensive attention. The lesson generalizes well beyond this CVE: every organization runs back-office ASP.NET applications — LMS platforms, HR portals, expense systems, ticketing tools, training catalogs — and every one of them is a candidate for exactly this class of flaw. The 2026 attack surface is not just the tier-one Microsoft estate. It is every ASP.NET process running on every server in the environment, and attackers are working through the long tail.
Signal 03 — A Hardcoded Cryptographic Secret Is a Whole-Product-Line Vulnerability
The hardcoded `machineKey` defect in KnowledgeDeliver is a useful case study in how a single line in a shipped configuration file can become an industry-grade vulnerability. Because the key is the same for every customer, any attacker who recovers it — through one compromised customer, one leaked installer, one decompiled binary — holds a working master key against the entire installed base. This is the same shape of failure that has produced default-credential incidents across decades of enterprise software, but it is structurally worse because the affected secret governs cryptographic integrity rather than authentication, and there is no analog to 'change the default password' that a customer can perform without the vendor's involvement until the patch ships. The fix has to happen at the build, not the deployment. For vendors of ASP.NET-based applications, the operational implication is direct: no cryptographic secret should ship with the product. The `machineKey`, like any signing or encryption key, must be generated per-instance at install time, or at first boot, by code the vendor controls. For procurement and vendor-risk teams, the implication is that this is now a question worth asking — and getting a documented answer to — in every ASP.NET application due-diligence review.
