CVE-2024-44000

What it actually does

CVE-2024-44000 is an unauthenticated authentication bypass in the LiteSpeed Cache WordPress plugin caused by insufficient protection of credential-like authentication material. In affected versions before 6.5.0.1, sensitive values related to user authentication could be written to web-accessible debug logging locations. A remote attacker can retrieve those values and use them to impersonate users, potentially including administrators, without needing a valid password or prior account access. With administrator-level access, the attacker can change site configuration, create users, install plugins or themes, execute code through WordPress extension mechanisms, and gain full control of the affected site.

Why it matters to the business

Successful exploitation can result in complete takeover of a WordPress site using LiteSpeed Cache, including content defacement, malware injection, credential theft, SEO spam, data exposure, payment-page manipulation, or use of the site as infrastructure for phishing and drive-by attacks. The CVSS score is critical at 9.8, EPSS is very high at 0.82143, and exploit maturity is listed as weaponized, so internet-facing sites running vulnerable versions should be treated as high-priority remediation targets even though the issue is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies a WordPress site running a vulnerable LiteSpeed Cache version. They then probe for publicly reachable log files or other exposed plugin-generated artifacts that may contain authentication-related values. If debug logging or vulnerable logging behavior has exposed those values, the attacker downloads the log content, extracts the relevant cookie or hash material, and replays it in a browser or scripted HTTP client to impersonate a legitimate user. If the impersonated identity has administrator privileges, the attacker can access the WordPress admin dashboard, create a new administrator account, modify plugin or theme files, install a malicious plugin, or use built-in administrative functions to achieve persistent control and possible code execution. After access is established, the attacker may clean up obvious traces, remove or rotate logs, add backdoors, inject malicious JavaScript, or use the compromised site for spam, phishing, malware delivery, or lateral movement into connected services.

How to fix it

Upgrade LiteSpeed Cache to version 6.5.0.1 or later immediately. If package managers or managed WordPress platforms are used, verify that the deployed plugin version is at or above the fixed release rather than assuming automatic updates completed. Remove any exposed historical debug logs that may contain sensitive authentication material, including web-accessible WordPress debug logs. Disable debug logging in production unless it is explicitly required, and ensure any necessary logs are stored outside the web root or protected by server access controls. Invalidate active WordPress sessions, rotate WordPress authentication salts and security keys, and force reauthentication for users. Review administrator accounts and remove any unknown or unauthorized users. If exploitation is suspected, reset privileged user passwords, audit installed plugins and themes, and inspect the filesystem for unauthorized changes or web shells.

How to confirm the fix worked

Confirm the installed LiteSpeed Cache plugin version is 6.5.0.1 or later from the WordPress admin plugin page, WP-CLI, filesystem metadata, or software inventory. Verify that debug logging is disabled or that logs are not stored in a web-accessible location. Attempt to request common exposed log paths from an unauthenticated browser or scanner and confirm they return 403, 404, or are otherwise inaccessible, not log content. Search the web root for old debug logs and confirm they have been removed or access-restricted. Validate that WordPress salts were rotated and that active sessions were invalidated after patching. Review WordPress administrator accounts, recently installed plugins, and recently modified theme or plugin files to confirm no unauthorized persistence remains.

Typical attack path

1. Fingerprint a target WordPress site and determine that the LiteSpeed Cache plugin is present.
2. Check whether the site is running an affected LiteSpeed Cache version prior to 6.5.0.1.
3. Request publicly accessible debug or cache-related log files, especially under web-accessible WordPress content paths.
4. Search retrieved log data for LiteSpeed Cache authentication-related values, cookies, hashes, roles, or user identifiers.
5. Replay the exposed authentication material in HTTP requests to impersonate a valid user.
6. Access the WordPress admin area if the exposed identity has sufficient privileges.
7. Create persistence by adding an administrator account, installing a malicious plugin, modifying theme files, or planting a web shell.
8. Use the compromised site for defacement, malware injection, SEO spam, credential theft, phishing, or further infrastructure abuse.

How to detect it

Review HTTP access logs, WAF logs, CDN logs, WordPress security plugin logs, authentication logs, and filesystem change records. Look for unauthenticated requests to web-accessible debug log files, particularly under WordPress content directories, followed by access to /wp-admin/ or privileged WordPress actions from the same IP address or user agent. Search logs for requests returning HTTP 200 for debug log paths, unusual spikes in requests for .log files, and suspicious user agents that fetch logs and then submit administrative actions. Inspect WordPress audit trails for new administrator accounts, unexpected password changes, plugin or theme installation, theme/plugin file editor usage, uploads of PHP files, and changes to wp-config.php or .htaccess. On the filesystem, look for unexpected PHP files in uploads, cache, plugin, or theme directories, recently modified plugin/theme files, and lingering debug logs containing authentication cookies, roles, hashes, or LiteSpeed Cache entries. If threat hunting at scale, correlate log-file access with later authenticated admin sessions from new geographies, hosting providers, VPNs, or IPs not previously associated with the affected site.

• GET /wp-content/debug.log
• POST /wp-content/debug.log
• /wp-content/debug.log
• GET /debug.log
• GET /wp-content/litespeed/debug.log
• litespeed_hash
• litespeed_role
• wordpress_logged_in_
• Cookie: litespeed_hash
• Cookie: litespeed_role
• /wp-admin/
• /wp-admin/plugin-install.php
• /wp-admin/theme-editor.php
• /wp-admin/plugin-editor.php
• /wp-admin/user-new.php
• /wp-admin/admin-ajax.php
• /wp-content/uploads/*.php
• /wp-content/cache/*.php
• /wp-content/plugins/*.php
• /wp-content/themes/*.php

What your security team should do

• Treat vulnerable internet-facing WordPress sites as urgent due to critical severity, high EPSS, and weaponized exploit maturity.
• Upgrade LiteSpeed Cache to 6.5.0.1 or later across all WordPress installations.
• Delete or restrict access to exposed historical debug logs, especially under web-accessible WordPress content directories.
• Rotate WordPress authentication salts and force all users, especially administrators, to log in again.
• Audit administrator accounts, plugin installations, theme modifications, and recent WordPress configuration changes for unauthorized activity.
• Search web access logs for unauthenticated requests to debug log paths and subsequent successful access to WordPress admin endpoints from the same source IPs.
• Disable production debug logging or store logs outside the document root with explicit server-side access controls.
• If signs of compromise are found, perform full incident response: preserve logs, remove persistence, reset privileged credentials, and inspect for web shells or injected JavaScript.