KnowledgeDeliver ViewState vulnerability: the operational risk of shared secrets

The case analysed by Mandiant on KnowledgeDeliver shows why reused ASP.NET keys in deployment templates can turn into large-scale compromise scenarios.

The case: a shared key becomes a systemic vulnerability

Google Threat Intelligence/Mandiant published an analysis of an incident involving a web server running KnowledgeDeliver, a Learning Management System developed by Digital Knowledge and used mainly in Japan. According to Mandiant, the vulnerability, now tracked as CVE-2026-5426, allowed unauthenticated remote code execution through ASP.NET ViewState deserialization.

For teams managing enterprise web applications, the most important detail is not the product name but the root cause: different installations used the same pre-shared machineKey values in the web.config file. In ASP.NET, these keys are used to sign and encrypt application data, including ViewState payloads. If an attacker knows the key, they can craft a malicious payload that the server treats as valid, potentially leading to deserialization of attacker-controlled code.

In practice, a secret designed to protect the application becomes a shared compromise point across multiple customers. This is a particularly critical pattern: a convenient but non-personalised deployment template can turn a single exposure into a repeatable risk across multiple internet-facing environments.

What changes operationally for organisations

For a company, public body or digital team, this case suggests immediate checks on three levels.

First: inventory of exposed ASP.NET/IIS applications. It is not enough to know which servers are online; organisations need to understand which applications use ViewState, which web.config files contain static machineKey values, and whether those keys are uniquely generated per environment. This review should include legacy applications, learning portals, extranets, vertical business systems and third-party solutions.

Second: governance of secrets in templates. Every deployment pipeline, base image, vendor package or provisioning script should be reviewed to rule out hardcoded or reused secrets. MachineKey values, API tokens, connection strings, certificates and encryption keys should never be copied across customers, environments or installations. Generation should be automated, traceable and separated by environment.

Third: detection capability. Mandiant reports post-compromise activity including in-memory .NET web shells, JavaScript file tampering, file system permission changes and workstation infection through a fake installer. This means file-based antivirus scanning alone may not be sufficient. Organisations need application logs, EDR, file integrity monitoring and event correlation.

In our work on web applications and infrastructure, services such as Dedaloop Cyber Cloud and Dedaloop Cloud Managed DevOps start from this point: making configurations, deployments, logging and operational responsibilities verifiable, so that security does not remain an occasional manual check.

Practical controls: hunting, hardening and response

The technical guidance published by Mandiant can be translated into an operational checklist.

For hunting, it is useful to monitor Windows Application Logs for ASP.NET events related to ViewState, in particular Event ID 1316 and messages with Event code 4009. According to Mandiant, some message variants may indicate failed attempts with an incorrect key, while others may suggest that integrity checks were passed and deserialization was attempted.

From a process perspective, organisations should monitor the behaviour of w3wp.exe, the IIS worker process. Anomalous launches of cmd.exe, powershell.exe or reconnaissance commands such as whoami should trigger high-priority alerts, especially on servers that do not normally run interactive shells. The same applies to sudden changes to .js, .aspx and .config files in the web root, or permissive ACL changes, for example through icacls.

For hardening, the most urgent actions are: generate unique and robust machineKey values for each instance; rotate keys if exposure is suspected; restrict access to non-public portals to known networks or VPNs; remove unnecessary write permissions; enable file integrity monitoring; verify that backups and restore procedures do not reintroduce vulnerable configurations.

If evidence is found, the response should not stop at replacing the key. JavaScript tampering or the use of in-memory web shells may already have extended the incident to end users and workstations. The response should therefore include server triage, endpoint analysis, web log review, verification of downloads served to users and review of potentially exposed credentials.

The broader lesson: software security and supply-chain responsibility

This episode concerns a specific LMS, but the principle applies to many enterprise architectures: what is distributed as a standard configuration can become a supply-chain vulnerability if it contains secrets, keys or assumptions that are not valid in production.

For software vendors, this means designing installations that force the generation of unique secrets, prevent insecure default configurations and make logging requirements visible. For customers, it means not treating purchased software as a black box: vendor solutions must also be included in the technical inventory, security controls and update plans.

A common mistake is separating governance from technical work: vendor policies on one side, IIS configurations on the other. In reality, effective mitigation requires both. Dedaloop Governance Consulting helps translate these risks into processes: who approves a new application, who verifies secrets, who controls updates, which logs must be available and which response SLAs are required from vendors.

The operational question is simple: if tomorrow it emerged that one of our vendor products used a shared key, would we be able to identify it, rotate it, verify compromise and communicate the impact? If the answer is unclear, the KnowledgeDeliver case is a good reason to start a targeted review now.

Approfondimenti Dedaloop

Fonti