What is the CVSS score of CVE-2023-40000?

CVE-2023-40000 has a CVSS 3.1 base score of 8.3 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L. EPSS exploitation probability: 82.0%.

Which versions of LiteSpeed Cache are affected by CVE-2023-40000?

WordPress websites running LiteSpeed Cache plugin (versions ≤5.7) are vulnerable to account compromise via persistent script injection attacks, with publicly available exploit code and no vendor…

Is there a public PoC exploit available for CVE-2023-40000?

Yes, a public proof-of-concept exploit is available for CVE-2023-40000. Prioritise patching immediately. EPSS: 82.0%.

How to fix or mitigate CVE-2023-40000?

Within 24 hours: Identify all WordPress installations running LiteSpeed Cache versions through 5.7 and immediately deactivate the plugin; document current versions in use. Within 7 days: Deploy Web Application Firewall rules to block stored XSS payloads in affected environments; implement Content Security Policy headers; enable logging and alerting for injection attempts. Within 30 days: Monitor LiteSpeed Cache for security updates; evaluate plugin replacement or alternative caching solutions; conduct security awareness training for WordPress administrators on this threat.

LiteSpeed Cache CVE-2023-40000

HIGH

Cross-site Scripting (XSS) (CWE-79)

2024-04-16 audit@patchstack.com

XSS Litespeed Cache

8.3

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

8.3 HIGH

AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Changed

Confidentiality

Low

Integrity

Low

Availability

Low

DescriptionCVE.org

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in LiteSpeed Technologies LiteSpeed Cache allows Stored XSS.This issue affects LiteSpeed Cache: from n/a through 5.7.

AnalysisAI

Stored cross-site scripting in LiteSpeed Cache for WordPress (versions up to and including 5.7) allows remote unauthenticated attackers to inject persistent malicious scripts that execute in the context of any user - including administrators - visiting affected pages. Publicly available exploit code exists and EPSS scores this at 82.03% (99th percentile), indicating very high probability of opportunistic exploitation across the millions of WordPress sites running this plugin. No CISA KEV listing at time of analysis, but the combination of high EPSS, public POC, and massive install base makes this a priority for WordPress operators.

Technical ContextAI

LiteSpeed Cache is a popular WordPress caching and site-acceleration plugin (CPE cpe:2.3:a:litespeedtech:litespeed_cache) developed by LiteSpeed Technologies, with an install footprint in the millions of WordPress sites. The root cause is CWE-79 (Improper Neutralization of Input During Web Page Generation), specifically the stored variant: user-controllable input is persisted by the plugin and later rendered into HTML responses without sufficient output encoding or input sanitization, so injected script payloads execute in any visitor's browser session. Because the payload is stored server-side, every subsequent page render delivers the attack - no per-victim social engineering is required after initial injection.

RemediationAI

Upgrade the LiteSpeed Cache plugin to a version later than 5.7 via the WordPress plugin updater or by downloading from wordpress.org/plugins/litespeed-cache; the affected-range upper bound in NVD data is 5.7, and Patchstack's advisory for this CVE identifies the fixed release as the next maintenance version, so any version newer than 5.7 (5.7.0.1 / 5.8 and later) should contain the sanitization fix - verify the exact patched version against the vendor changelog before deploying. If immediate patching is not possible, compensating controls include temporarily deactivating LiteSpeed Cache (accepting the performance hit and loss of caching/optimization features), restricting access to plugin-managed input fields and admin endpoints behind IP allowlists or WAF rules that block typical XSS payloads (with the trade-off of false positives on legitimate rich content), and deploying a strict Content-Security-Policy that disallows inline script (which can break themes or other plugins that rely on inline JS). Audit existing cached content and stored plugin data for previously injected payloads, since stored XSS persists across the patch.