An exposed key transforms an LMS into attack vector: CVE-2026-5426 Cobalt Strike in KnowledgeDeliver

Author: Published 4 min de lectura 158 reading

The images in this article were generated with artificial intelligence. How we publish

A high-severity security failure that was already patched in Digital Knowledge Knowledge Deliver - a learning management system (LMS) with a wide presence in Japan - was exploited as zero-day to install the web shell known as Godzilla (BLUEBEAM) and, from there, deploy Cobalt Strike Beacon on the victims' machines. Vulnerability, recorded as CVE-2026-5426 with a CVSS of 7.5, was used for the re-use of shared secrets: LMS deployments used a standardized web.config file of the supplier containing values machineKey in clear for ASP.NET, which allowed attackers to create malicious ViewState loads and cause remote deerialization without authentication.

The technical vector is classic but dangerous: ASP.NET uses the machine key to sign and encryption data like the _ _ VIEWSTATE, and if that secret is known, an attacker can forge a ViewState that, by being deerialized by the server, executes arbitrary code. Microsoft already documented in 2025 the malicious use of filtered machineKey keys, and the abuse chain has been repeated in other products (e.g. Sitecore XM, Gladinet CentreStack and TrioFox), which emphasizes that the problem lies in both individual failures and unsafe deployment patterns.

An exposed key transforms an LMS into attack vector: CVE-2026-5426 Cobalt Strike in KnowledgeDeliver
Image generated with IA.

In the campaign observed by Google Mandiant and the Google Threat Intelligence Group (GTIG) the attacker not only obtained remote execution: he left a web shell that allowed to run commands, changed file system permissions (giving full access to "Everyone" in the application directory) and altered a JavaScript script to show a false alert that induced users to download a malicious "authentication plugin." This downloaded installer finally contained Cobalt Strike Beacon; the analysis also showed that the payload was encrypted with a key that included the name of the organization, suggesting targeted and prepared attacks specifically for each victim.

The implications are clear and worrying: a single leaked key can compromise multiple instances of the same product, especially when suppliers distribute standard configurations with embedded secrets. This makes the settings and configuration files a high impact attack surface, and poses risks of climbing from initial web access to laterality and persistence in the organization's network.

From an operational point of view, immediate and long-term measures are complementary. In hot, any installation prior to 24 February 2026 should be updated to the parched version of KnowledgeDeliver; in addition, the web server and public file repositories should be inspected by engagement signals: web shell files (e.g. aspx / php with opfuscated code), recent modifications to JavaScript that inject external loads, system-level changes in web directories and outgoing traffic to suspicious domains. In the containment phase it is recommended to isolate committed instances, capture forensic images before cleaning, rotate all the exposed credentials and block the domains and IP addresses associated with the campaign on the network.

An exposed key transforms an LMS into attack vector: CVE-2026-5426 Cobalt Strike in KnowledgeDeliver
Image generated with IA.

To reduce the likelihood of reexposure, organizations should remove any hard-coded machineKey and make sure that the keys are single installation. Good practices include generating the keys in the host during deployment (or using a secret management service such as Azure Key Vault or HashiCorp Vault), enabling the proper protection of ViewState (MAC and encrypted according to ASP.NET configuration), and applying integrity controls over web files and static resources. It is also crucial to implement monitoring that detects typical operating chains (requests with _ _ VIEWSTATE anomalous, Cobalt Strike beaconing patterns) and to strengthen the detection of post-exploitation behaviors.

In terms of detection, it is appropriate to review web log and proxy for HTTP requests containing unusually long or uncoded _ _ _ VIEWSTATE values, search for output traffic that matches Cobalt Strike Beacon patterns and audit the web server file system to detect changes in permissions and modified files on commitment dates. The community and technical documentation on unsafe deerialization and on Cobalt Strike provide indicators and detection techniques that can be useful; for example, the explanation of risk of deerialization in OWASP and the Cobalt Strike report on MITRE ATT & CK are practical resources for security equipment: OWASP on unsafe deerialization and MITRE ATT & CK - Cobalt Strike (Beacon). To understand the performance of the ViewState at ASP.NET, Microsoft's historical documentation on this mechanism is available: Microsoft documentation about ViewState.

Beyond the spot patch, this incident is a call to suppliers and customers: manufacturers should not distribute default secrets in their packages and organizations that deploy software should treat templates and devices from the supplier as a code that requires revision and hardening. The management of secrets, periodic rotation and the principle of less privilege in file and service permits are essential countermeasures to prevent the same debit configuration from turning hundreds of facilities into chained victims of a single leak.

Coverage

Related

More news on the same subject.