Security Alert: KnowledgeDeliver allows remote execution and deployment of web shells with ViewState signed thanks to a shared key (CVE-2026-5426)

A critical failure in KnowledgeDeliver, a learning management system (LMS), allowed remote attackers to sign and deerialize malicious ViewState payloads and deploy the web shell .NET known as Godzilla, winning code execution at operating system level without authentication. Vulnerability, recorded as CVE-2026-5426 is derived from a bad configuration practice: the presence of a preshared and hardcodeated machineKey in the web.config file provided by the supplier for multiple customers.

In technical terms, the problem is not deerialization itself, but the possibility of sign ViewState payloads legitimately because all deployments used the same cryptographic key. With that key the attackers built false ViewState that ASP.NET accepted as valid and, by means of deerialization, they executed code in memory that allowed to plant a web shell and later a Cobalt Strike beacon.

The incidents described by Mandiant show a classic chain of engagement: initial explosion by ViewState, modification of application resources to deceive users (e.g. a false installer), and loading of an encrypted and directed payload - which, according to researchers, even used the name of the target organization in the encryption key - to avoid generic detection. The Mandiant report with details is available here: Mandiant / Cloud.

Godzilla is not new in this vector: Microsoft and other response teams have documented previous attacks that abuse exposed or reused machineKeys to generate signed ViewState and achieve remote execution in ASP.NET applications A Microsoft analysis of similar campaigns can be found on your blog: Microsoft Security. These incidents stress that the reuse of cryptographic keys in multi-client deployments is a systemic risk.

The implications for organizations using KnowledgeDeliver or ASP.NET platforms are clear and serious: Unauthorised remote access, persisting by web shells in memory, credentials theft and lateral movement. In addition, the modification of static application files to serve false installers turns the platform into a commitment vector for endpoints and internal networks.

If your organization uses KnowledgeDeliver or similar ASP.NET applications, the first immediate actions should be to contain the damage: isolate affected servers, collect IIS and system logs, capture memory if possible and keep copies of the web.config for forensic analysis. Look for Godzilla and Cobalt Strike signs: outgoing traffic to unusual domains or PIs, processes or charges in memory without disk file, new entries in scheduled tasks and modifications to JavaScript files and the root of the web.

In parallel, rotate the problem keys: generation and deployment Unique machineKeys per installation and make sure that the ViewState signature and encryption are properly configured (e.g. require ViewStateMac = true and ViewStateEncrytionMode appropriate). Do not trust the supplier's default settings; please note that each client has unique and secretly generated cryptographic parameters.

From the preventive point of view, apply patches and configuration settings of the sell as soon as they publish corrections, activate compensatory controls such as Web Application Firewalls with rules to detect abnormal ViewState patterns and display detection on endpoints and network to identify Cobalt Strike activity and C2 connections. Review file integrity and sign critical artifacts helps detect malicious changes in web resources that serve installers or scripts.

For detection and response, Use EDR / IR to search for deerialization and execution behaviors in w3wp.exe or dotnet.exe processes, examine IIS logs for unusual payloads in ViewState parameters (_ _ VIEWSTATE) and compare JavaScript file hashes to a known inventory. Also consider YARA rules or specific signatures for Godzilla / BlueBeam and network rules for Cobalt Strike patterns. The training of users not to install "security plugins" coming from the LMS's own public website also reduces the success of the opponent's deception stage.

Finally, this campaign is a reminder that the operational security of third-party-managed software requires active verification by customers. Requiring safe supply practices, independent audits and the ability to rotate secrets without the intervention of the supplier are controls that will mitigate similar risks in the future. For reference cases on previous attacks that abuse machineKeys and ViewState, in addition to Mandiant and Microsoft, you can review analysis of related campaigns published by other researchers such as ASEC: ASEC / AhnLab.