KnowledgeDeliver LMS flaw exploited as zero-day to deploy in-memory web shell

A zero-day vulnerability in Digital Knowledge’s KnowledgeDeliver LMS was exploited in the wild to gain remote code execution and deploy an in-memory web shell on a compromised server. Mandiant says the flaw stems from shared ASP.NET machine keys used in some deployments before February 24, 2026.

The issue is tracked as CVE-2026-5426. According to Mandiant’s KnowledgeDeliver analysis, an unknown threat actor used the flaw to inject malicious code into an LMS platform and target users who visited the compromised site.

KnowledgeDeliver is a learning management system from Japan-based Digital Knowledge. The product is used for e-learning, course management, training delivery, and student or employee learning workflows, which makes a compromise especially risky for organizations that rely on it for internal education portals.

The flaw comes from shared ASP.NET machine keys

The vulnerability affects KnowledgeDeliver deployments that used a standardized web.config file with hardcoded ASP.NET machineKey values. These keys help ASP.NET protect ViewState data, authentication-related data, and other signed or encrypted application state.

The Mandiant advisory says deployments may have been implemented with a pre-shared ASP.NET machine key. If an attacker knows that key and can reach the application, they can craft a malicious ViewState payload that the server accepts and deserializes.

The NVD entry for CVE-2026-5426 describes the bug as a hard-coded ASP.NET/IIS machineKey issue that lets attackers bypass ViewState validation and achieve remote code execution through malicious ViewState deserialization.

Detail	Information
CVE	CVE-2026-5426
Affected product	Digital Knowledge KnowledgeDeliver LMS
Attack type	ASP.NET ViewState deserialization
Root cause	Shared or hardcoded ASP.NET machine keys
Affected deployments	Deployments using default ASP.NET configuration before February 24, 2026
Main payload	BLUEBEAM, also known as Godzilla

How attackers turned ViewState into code execution

ASP.NET ViewState helps preserve page state between browser requests. It can become dangerous when attackers know the machineKey that signs or protects that data, because they can create a malicious ViewState value that the server treats as trusted.

Mandiant says the attacker sent crafted payloads through the __VIEWSTATE parameter in HTTP requests. That forced the vulnerable server to deserialize attacker-controlled data, which opened the door to remote code execution on the IIS server.

This technique follows a broader pattern. In 2025, Microsoft warned about ASP.NET machine key attacks where threat actors used publicly available keys to inject code and deploy the Godzilla post-exploitation framework.

BLUEBEAM ran inside the IIS process

After gaining access, the threat actor deployed BLUEBEAM, a .NET-based in-memory web shell also known as Godzilla. Mandiant says the web shell ran inside the IIS worker process, w3wp.exe, which reduced the value of traditional file-based detection.

Because the web shell operated in memory, attackers could send encrypted HTTP POST requests to execute commands and run additional payloads. This gave them a stealthier path to control the server without dropping an obvious web shell file to disk.

The attacker also used icacls to weaken file system permissions on the web application directory. That step gave broader access to the compromised host and made later tampering easier.

• Remote code execution was achieved through malicious ViewState payloads.
• BLUEBEAM ran inside w3wp.exe as an in-memory web shell.
• The attacker modified file permissions with icacls.
• Legitimate JavaScript files were changed to target LMS users.
• Users were pushed toward a fake security plugin that delivered Cobalt Strike Beacon.

The attack also targeted LMS users

The compromise did not stop at the server. Mandiant observed JavaScript tampering inside the LMS, where legitimate script files were modified to show a fake security alert to users.

The message prompted visitors to install a so-called authentication plugin. In reality, the download led to a Cobalt Strike Beacon infection, turning the compromised LMS into a delivery point for malware against downstream users.

The payload was encrypted with a key derived from the victim organization’s name. That detail suggests the attacker prepared the follow-on infection for a specific target rather than using only a generic malware chain.

Attack stage	Observed behavior	Defensive focus
Initial exploit	Malicious ViewState sent to KnowledgeDeliver	Rotate machine keys and review IIS logs
Server access	BLUEBEAM loaded in memory inside w3wp.exe	Watch for unusual web server child processes
Permission change	icacls used to loosen web directory permissions	Monitor file system ACL changes
User targeting	Modified JavaScript showed a fake plugin prompt	Use file integrity monitoring on web assets
Endpoint infection	Cobalt Strike Beacon delivered to users	Hunt browser downloads and beacon activity

Detection depends on logs and process behavior

Organizations should review Windows Application logs for ASP.NET Event ID 1316. Mandiant says some logs may show ViewState validation failures or invalid ViewState errors, including cases where payload deserialization may still have been attempted.

Process monitoring also matters. Defenders should investigate cases where w3wp.exe launches suspicious child processes such as cmd.exe or powershell.exe, especially if those events appear near unusual HTTP POST traffic.

File integrity monitoring can help catch changes to .js, .aspx, and .config files. In this campaign, modified JavaScript played a central role in the attempt to infect users who trusted the LMS portal.

• ASP.NET Event ID 1316 from Windows Application logs
• Invalid ViewState or failed ViewState integrity messages
• w3wp.exe spawning cmd.exe, powershell.exe, or reconnaissance commands
• Unexpected changes to JavaScript and ASP.NET configuration files
• Strange User-Agent strings made from combined browser identifiers
• Connections tied to suspicious LMS-delivered scripts or fake plugin downloads

Admins should rotate machine keys immediately

The main remediation is clear: every KnowledgeDeliver deployment needs a unique, cryptographically strong ASP.NET machineKey. Reusing a key across deployments turns one exposed secret into a reusable exploit path against other internet-facing systems.

The Mandiant vulnerability disclosure says organizations should generate a unique machineKey for each KnowledgeDeliver instance. It also notes that Digital Knowledge implemented an updated deployment procedure on February 24, 2026.

Admins should also restrict LMS access to trusted IP ranges where possible, review server logs for earlier exploitation, rebuild compromised systems from clean sources, and check whether users downloaded suspicious files after visiting the LMS.

Priority	Action	Why it matters
High	Rotate ASP.NET machine keys	Stops reuse of known shared secrets
High	Review IIS and ASP.NET logs	Finds ViewState exploitation attempts
High	Check for modified JavaScript files	Identifies user-facing malware delivery
Medium	Restrict LMS access by IP range	Reduces exposure to unauthenticated attackers
Medium	Monitor w3wp.exe child processes	Detects suspicious post-exploitation behavior

Why this vulnerability matters beyond one LMS

KnowledgeDeliver’s role as an LMS increases the impact of the flaw because users trust the platform and often run downloads or authentication prompts connected to internal training systems. A compromised LMS can therefore become both a server intrusion and a user-targeting platform.

The official Digital Knowledge product page describes KnowledgeDeliver as an integrated e-learning platform with learning, content creation, and operational management features. Those broad workflows create many possible touchpoints across enterprise and education environments.

The case also reinforces Microsoft’s earlier guidance on machine keys. Microsoft’s ViewState guidance recommends avoiding publicly available keys, rotating keys regularly, and monitoring configuration files for unauthorized changes.

For defenders, the lesson is simple. Shared cryptographic secrets should never ship as reusable defaults, especially in internet-facing applications. Once attackers obtain the key, ViewState protection can turn from a security control into an execution path.

The CVE-2026-5426 record remains an important reference point for tracking remediation and scoring updates. Organizations that run KnowledgeDeliver should treat the issue as urgent until they confirm key rotation, exposure controls, log review, and endpoint checks.

Mandiant’s incident report shows how quickly a configuration flaw can grow into a broader compromise. One shared machine key enabled server access, an in-memory web shell, JavaScript tampering, and Cobalt Strike delivery to users who trusted the affected LMS.

FAQ