What Happened
Between July 2025 and February 2026, attackers exploited a deserialization vulnerability in KnowledgeDeliver LMS to install the Godzilla web shell on customer systems. The vulnerability, tracked as CVE-2026-5426, allowed remote code execution through ASP.NET ViewState manipulation. The root cause: every KnowledgeDeliver installation deployed before February 24, 2026, shipped with an identical machine key in its web.config file.
Attackers reverse-engineered the shared machine key from any accessible installation, then used it to craft malicious ViewState payloads that executed arbitrary code on every other system running the same configuration.
Timeline
July 2025: Attackers compromise 85 Microsoft SharePoint servers using similar ViewState deserialization techniques, demonstrating the viability of the attack pattern.
July 2025 - February 2026: Threat actors exploit the shared machine key in KnowledgeDeliver installations to deploy Godzilla web shells. The exact number of affected systems remains undisclosed.
February 24, 2026: Vendor updates deployment process to generate unique machine keys per installation.
Post-incident: Mandiant publishes analysis confirming the attack vector and scope.
Which Controls Failed or Were Missing
Configuration Management
The vendor distributed a standardized web.config file containing a hardcoded machine key to all customers. No process existed to generate unique keys during installation or deployment. This meant:
- Every installation was cryptographically identical
- Compromise of one system revealed the keys for all systems
- No detective control could identify installations sharing keys
Secure Defaults
The default configuration created systemic risk. Once attackers obtained the shared machine key from any single installation—through reconnaissance, a test deployment, or even purchasing legitimate access—they possessed credentials valid across the entire customer base.
Input Validation
The application accepted and processed ViewState data without validating its integrity beyond checking the machine key signature. Since attackers possessed valid keys, their malicious payloads passed validation and triggered deserialization of untrusted data.
Change Detection
No monitoring existed to detect:
- Unusual ViewState payloads
- Deserialization of unexpected object types
- Web shell deployment patterns
- Modifications to application directories post-deployment
What the Relevant Standards Require
OWASP ASVS v4.0.3
V5.5.2: "Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries."
The application failed this requirement by deserializing ViewState content without additional validation beyond machine key verification. When the machine key itself became compromised, no secondary protection existed.
V2.6.3: "Verify that secrets, API keys, and passwords are generated using the cryptographic module approved by FIPS 140-2 or equivalent."
Distributing a single shared machine key to all installations violates the principle that cryptographic secrets must be unique per system. The key became a shared secret across thousands of deployments—effectively making it not a secret at all.
NIST 800-53 Rev 5
SC-12 (Cryptographic Key Establishment and Management): Organizations must establish and manage cryptographic keys using automated mechanisms with minimal human intervention.
The vendor's manual distribution of identical keys across all deployments directly contradicts this control. Each installation should have generated unique keys during setup.
CM-6 (Configuration Settings): Organizations must establish and document configuration settings, including security configuration parameters.
The standardized web.config approach failed to account for the security implications of shared cryptographic material. Configuration management should have included procedures for unique key generation per deployment.
ISO 27001:2022
Annex A 8.24 (Use of cryptography): Rules for the effective use of cryptography, including cryptographic key management.
Distributing identical cryptographic keys violates fundamental key management principles. Each key should have a defined lifecycle, limited scope, and unique identity. A shared key across all installations has none of these properties.
Lessons and Action Items for Your Team
Generate Unique Secrets Per Deployment
Review every application configuration file in your environment. Any cryptographic key, connection string password, or API credential must be unique per installation. If you find shared secrets:
- Inventory all systems using the shared value
- Generate unique replacements using a cryptographically secure random number generator
- Deploy new secrets with a rollover period that maintains availability
- Revoke the shared secret after migration completes
For ASP.NET applications specifically, machine keys must be generated using the RNGCryptoServiceProvider class or equivalent. Never copy machine keys between systems, even within your own infrastructure.
Audit Vendor-Provided Configurations
Your vendors' default configurations often prioritize ease of deployment over security. Before deploying any third-party application:
- Extract and review all configuration files
- Identify any hardcoded credentials, keys, or certificates
- Verify that secrets are unique to your installation
- Document the configuration baseline and any changes you make
If the vendor's installation process doesn't generate unique secrets, open a security ticket. This is a fundamental security requirement, not a feature request.
Implement ViewState Protection
If you run ASP.NET applications, verify that ViewState includes both encryption and integrity protection:
<pages enableViewStateMac="true"
viewStateEncryptionMode="Always" />
Even with unique machine keys, ViewState should never be your only security boundary. Implement additional deserialization protections:
- Restrict ViewState to specific page types using
ViewStateUserKey - Monitor for unusually large ViewState payloads
- Consider disabling ViewState entirely for pages that don't require it
Monitor for Web Shell Indicators
The Godzilla web shell and similar tools leave detectable artifacts. Configure your SIEM or EDR to alert on:
- New .aspx, .ashx, or .asmx files in application directories
- Processes spawned by w3wp.exe (IIS worker process) that execute system commands
- Outbound connections from web server processes to unexpected destinations
- File modifications in web application directories outside deployment windows
Test Your Deserialization Attack Surface
Run a focused assessment of every application that deserializes external input:
- Identify all deserialization points (JSON, XML, ViewState, Java objects, pickles)
- Verify that each implements type whitelisting or equivalent protection
- Test whether you can inject unexpected object types
- Confirm that deserialization errors fail safely without revealing internal state
The attack pattern demonstrated here—exploiting shared secrets to craft malicious serialized payloads—applies to far more than ASP.NET ViewState. Python pickle, Java RMI, Ruby Marshal, and PHP unserialize all present similar risks when processing untrusted input.
This incident reinforces a fundamental principle: shared secrets aren't secrets. Every cryptographic key, credential, and configuration parameter must be unique per deployment. When vendors ship standardized configurations, that's your signal to generate new values before the system goes into production.
