A critical unauthenticated remote code execution vulnerability, tracked as CVE-2026-5426 (CVSS 7.5), has been confirmed in KnowledgeDeliver, a Learning Management System developed by Digital Knowledge and widely deployed in Japan. Attackers exploited the flaw as a zero-day to install the Godzilla web shell (also known as BLUEBEAM) and subsequently drop a Cobalt Strike Beacon backdoor on compromised hosts. Active in-the-wild exploitation prior to any patch being available has been confirmed by SecurityWeek.
Zero-day exploitation ending in a Cobalt Strike Beacon is not a nuisance incident, it is a staging post for ransomware, data exfiltration, or lateral movement across an internal network. LMS platforms are frequently connected to HR directories and single sign-on providers, meaning a foothold on an LMS host can translate quickly into broader identity compromise.
For security teams, the specific danger here is the nature of the root cause: hardcoded cryptographic keys shipped inside a vendor-supplied configuration file. Organisations that followed the vendor's own installation guidance were, by default, vulnerable. Standard vulnerability scanning would not surface this, there is no missing patch to flag until the vendor issued one. Detection had to come from behavioural monitoring or web shell indicators rather than from asset management tooling.
The Godzilla web shell gives an attacker interactive command execution and the ability to stage further payloads without triggering many signature-based controls. Once Cobalt Strike Beacon is running, the attacker has an encrypted, resilient command-and-control channel that blends with normal HTTPS traffic. Incident response at that stage is significantly more costly than catching the initial web shell.
The vulnerability originates in how ASP.NET handles ViewState, the mechanism used to persist page state between HTTP requests. ASP.NET uses a machineKey value defined in web.config to encrypt and cryptographically sign ViewState payloads before they are sent to the client and again when they are returned by the browser.
The problem, as Mandiant Threat Intelligence details, is that Digital Knowledge supplied a standardised web.config file containing hardcoded machineKey values as part of its installation package. Every KnowledgeDeliver instance deployed using that default configuration therefore shared an identical signing key. An attacker who knows that key, and it is reasonable to assume such values circulate once discovered, can craft a ViewState payload that ASP.NET will treat as valid and trustworthy. When the application deserialises that payload, the attacker achieves unauthenticated remote code execution without supplying any credentials.
This class of attack is not new to ASP.NET environments, but it remains reliably effective wherever shared or default machineKey values persist. The attacker's ability to trigger code execution through a standard HTTP request to an apparently normal page endpoint makes network-layer detection particularly difficult. Behavioural detections, unusual child processes spawned by IIS worker processes, unexpected outbound connections from the web server, offer a more realistic detection path than packet inspection alone.
Defenders should treat any known-shared machineKey the same way they treat a leaked password: it must be rotated immediately, not scheduled for the next maintenance window.
Any organisation running KnowledgeDeliver that deployed the application using the vendor-supplied default web.config prior to 24 February 2026 is affected. Installations where the machineKey was never explicitly replaced with a unique, cryptographically generated value carry the same exposure regardless of when they were set up. The vulnerability does not require the attacker to be authenticated, nor does it require any specific user interaction — a reachable HTTP endpoint is sufficient.
While current reporting focuses on Japanese deployments, the broader attack surface for any internet-facing ASP.NET application sharing a known machineKey is identical in principle. Organisations in the MEA region that have licensed or deployed KnowledgeDeliver as part of e-learning or corporate training infrastructure should assume exposure until the web.config has been audited and the key replaced.
Audit your web.config immediately. Open the web.config file on every KnowledgeDeliver host and check the machineKey element. If the value matches the vendor default or if multiple instances share an identical key, treat those systems as compromised until proven otherwise.
Generate a unique machineKey per instance. Use a cryptographically secure method to produce a fresh, randomly generated key specific to each deployment. Microsoft's IIS Manager tooling or purpose-built generation utilities are appropriate for this. A reused or weak key provides no protection even after patching.
Apply the vendor patch and verify the fix. Install the official patch from Digital Knowledge and confirm through post-patch testing that the default key is no longer present. Patching alone is insufficient if the web.config still carries the original shared value.
Hunt for web shell and Cobalt Strike artefacts. Review IIS logs for anomalous POST requests to pages that do not normally accept form submissions. Check for unexpected files in web root directories and examine process creation logs for IIS worker processes (w3wp.exe) spawning command-line tools. Known indicators of compromise for Godzilla/BLUEBEAM and Cobalt Strike Beacon should be swept across endpoint telemetry and network logs.
Restrict access at the network layer. Where operational requirements allow, limit inbound access to the KnowledgeDeliver application to known organisational IP ranges. This does not eliminate the vulnerability but meaningfully reduces the population of potential attackers who can reach the endpoint.
The underlying deserialization mechanism is a feature of ASP.NET, so any ASP.NET application deploying with a shared or default machineKey is theoretically exposed in the same way. CVE-2026-5426 is assigned specifically to KnowledgeDeliver because of the vendor's distribution of a standardised configuration containing hardcoded key values.
Both steps are necessary. Rotating the machineKey removes the attacker's ability to forge valid ViewState payloads using the shared secret. The vendor patch addresses the underlying vulnerability. Doing one without the other leaves residual risk; the machineKey rotation is the more urgent action given active exploitation.
Look for unexpected files in IIS web directories, unusual outbound connections from the web server, and IIS worker processes spawning shells or scripting engines. Cobalt Strike Beacon in particular will generate periodic encrypted beacons to attacker infrastructure — anomaly-based network monitoring should surface that behaviour.
If the system is internet-facing and you cannot confirm the machineKey has been replaced within hours, isolating it from public access until remediation is complete is a proportionate response. Internal-only deployments with strong network segmentation carry lower immediate risk but still require the same remediation steps.
