KnowledgeDeliver Zero-Day Actively Exploited to Plant Godzilla Web Shell

A critical zero-day vulnerability in the KnowledgeDeliver learning management system is being actively exploited in the wild, with attackers using it to deploy the Godzilla web shell on compromised servers, according to BleepingComputer.

What Happened

Threat actors identified and weaponized a critical flaw in KnowledgeDeliver before any patch existed — the textbook definition of a zero-day. The payload of choice is Godzilla, a sophisticated PHP/JSP web shell that communicates over AES-encrypted channels. That encryption detail matters: Godzilla's traffic is designed to blend into normal HTTPS flows, making it invisible to plaintext signature-based detection.

Godzilla is not a simple backdoor. It is a full post-exploitation framework: file manager, command execution, database client, and network pivot tool — all accessible over an encrypted, authenticated session from any browser.

Why It Matters

Zero-days combined with web shell deployment is one of the most dangerous attack patterns in the threat landscape:

• Persistence is instant. Once planted, the shell survives patches, restarts, and redeployments unless it is explicitly removed.
• Detection is hard. Encrypted C2 traffic and a shell file that can be named anything means standard WAF rules and log scanning will likely miss it.
• LMS platforms are high-value targets. They sit inside corporate or institutional networks, often handle SSO integrations, and store PII for every enrolled user.

No patch is available. This is an open, unmitigated vulnerability being actively abused right now.

What To Do

1. Audit your web root for new or modified files. Focus on directories writable by the web process — upload folders, temp paths, plugin directories. Command to find recently modified PHP files:

find /var/www -name "*.php" -newer /var/log/nginx/access.log -ls

2. Grep for Godzilla signatures. Godzilla shells use AES decryption routines and base64 decode chains. Scan your web root:

grep -rn "base64_decode\|openssl_decrypt" /var/www/ --include="*.php"

3. Review POST access logs. Look for POST requests to PHP files in unexpected paths, especially with small response bodies (200 OK, <500 bytes). These are hallmarks of shell command responses.

4. Isolate immediately if you find anything. Take the instance offline, preserve disk images before touching anything, and engage an IR team. Deleting the shell alone is insufficient — the initial access vector remains open.

5. Do not wait for a patch to start hunting. The vulnerability is unpatched, but compromise indicators exist now. Assume breach posture and work backward.

6. Monitor KnowledgeDeliver's official channels for a CVE assignment and emergency patch. Apply it the moment it drops — and verify the patch actually closes the upload/execution path, not just the reported surface.

If you are running KnowledgeDeliver in any capacity — self-hosted, managed, or as part of a third-party LMS stack — treat this as an active incident until you have evidence to the contrary.