KnowledgeDeliver Zero-Day Let Attackers Walk In With Keys They Already Had
Mandiant has published details on the exploitation of a zero-day vulnerability in KnowledgeDeliver, a learning management system built by Digital Knowledge and popular in Japanese enterprise and education circles. The flaw, CVE-2026-5426, carries a CVSS score of 7.5 and the root cause is embarrassingly avoidable: hardcoded machineKey values baked into a standardised web.config file shipped across all installations.
For anyone unfamiliar with ASP.NET internals, machineKeys handle encryption and signing of data including the ViewState mechanism, which persists page state between requests. If an attacker knows your machineKey, they can craft a malicious ViewState payload and send it in an HTTP request. The server dutifully deserialises it. Bad things follow.
The problem with hardcoded keys shared across independent deployments is obvious in hindsight. One known key equals access to every installation running the same config. This is not a novel attack class either. Identical techniques have been used against Sitecore and CentreStack deployments, and the Godzilla post-exploitation framework has shown up in similar incidents before.
It showed up here too. Attackers deployed Godzilla web shells (also tracked as Bluebeam) running in memory, giving them the ability to execute arbitrary commands and drop further payloads without leaving much on disk. They used that foothold to tamper with directory permissions, inject a malicious script into a JavaScript file within the web application, and serve users a fake security alert pushing a bogus plugin installation. Classic social engineering layered on top of a server-side compromise.
The end goal was a Cobalt Strike backdoor. Notably, the payload was encrypted using a key containing the victim organisation's name, which strongly suggests this was not opportunistic scanning. Someone prepared this specifically for the target.
Mandiant has released indicators of compromise tied to the campaign. Any KnowledgeDeliver deployment running software from before 24 February 2026 should be considered potentially compromised. The recommended steps are to rotate machineKey values immediately, restrict external access to the LMS, and audit logs for signs of ViewState abuse or unexpected process execution from the web application.
The broader lesson here is one the industry keeps having to relearn: shipping identical cryptographic secrets across every customer installation is not a configuration decision, it is a vulnerability waiting for a CVE number.