CVE-2023-40000

What it actually does

This is a stored cross-site scripting flaw caused by insufficient neutralization of attacker-controlled input before it is saved and later rendered into a web page. An unauthenticated network attacker can inject markup or JavaScript that persists in application-managed content or configuration and executes in the browser context of users who view the affected page. Because the script runs under the trusted site origin, it can read accessible page data, interact with the application as the victim user, perform unauthorized state-changing actions, and potentially pivot to administrative takeover if a privileged user views the poisoned content. The supplied product metadata is inconsistent: the description identifies LiteSpeed Cache through version 5.7, while the affected package/fix data lists craftcms/cms with a Git fix commit a54e725a3ad01da409d466e30369855642845a41; asset owners should validate both product exposure and the exact upstream advisory mapping before closing remediation.

Why it matters to the business

Successful exploitation can let an external attacker compromise user sessions, alter website content, abuse administrator privileges, redirect visitors, inject malicious scripts, or damage customer trust through website defacement or credential theft. The risk is elevated because exploitation is reported as weaponized and the EPSS score indicates meaningful real-world exploitation likelihood, even though it is not currently listed in CISA KEV and is not known from the supplied data to be used in ransomware campaigns. Public-facing CMS, cache, or web publishing components should be prioritized because exploitation can affect both internal administrators and external site visitors.

How an attack unfolds

An attacker first identifies an internet-facing site running the affected component or code path. They then submit crafted input containing HTML or JavaScript through a field, request parameter, content object, configuration value, cache-related artifact, or other web workflow that is accepted without proper sanitization. The application stores or reuses this value and later emits it into generated HTML without context-appropriate output encoding. When another user, especially an administrator or editor, loads the affected page, the browser executes the attacker's script as if it came from the legitimate site. The script can then use the victim's authenticated browser context to read exposed data, capture anti-CSRF tokens or page contents, make unauthorized requests, create new administrative users where possible, modify content, add redirects, or stage additional client-side malware. If the vulnerable component is used on a high-traffic public site, the same stored payload can repeatedly affect many viewers until removed.

How to fix it

Upgrade to a fixed release or commit for the actually deployed product. For the supplied package data, craftcms/cms Git users should ensure they include commit a54e725a3ad01da409d466e30369855642845a41 or a later trusted upstream release containing that fix. For environments matching the description rather than the package metadata, upgrade LiteSpeed Cache to a version newer than 5.7 that contains the vendor's fix. Because the provided advisory metadata mixes product names, verify the vulnerable component against the vendor advisory, lockfiles, plugin inventory, and deployed code before marking the issue remediated. As compensating controls until patching is complete, restrict administrative access, disable or remove the vulnerable plugin/component if feasible, block untrusted submission paths with a WAF rule for script-bearing payloads, enforce strong Content Security Policy to reduce script execution impact, require reauthentication for sensitive administrative actions, and purge caches or stored content that may contain injected payloads after remediation.

How to confirm the fix worked

Confirm the deployed version or commit is no longer within the affected range. For Git-based deployments, verify that commit a54e725a3ad01da409d466e30369855642845a41 or a later descendant is present in the deployed artifact. For LiteSpeed Cache deployments, confirm the installed plugin/component version is above 5.7 and matches the vendor-fixed release. Review dependency manifests, plugin inventories, container images, build artifacts, and production file checksums rather than relying only on package manager metadata. After upgrading, reproduce a safe benign XSS test in a non-production environment using an inert marker payload and verify that input is encoded, stripped, or rejected in every rendering context. Purge application, page, CDN, and object caches so previously stored payloads cannot continue to execute. Finally, scan rendered pages and stored content repositories for script-bearing strings and confirm no unexpected administrative users, content changes, redirects, or JavaScript includes were created during the exposure window.

Typical attack path

1. Fingerprint the target website to identify the affected CMS, plugin, cache component, or vulnerable code path.
2. Locate an input surface that is stored or later rendered, such as a content field, comment-like workflow, configuration value, cache metadata field, or request parameter reflected into generated pages.
3. Submit a crafted payload containing script-capable markup or event-handler attributes.
4. Wait for the application to save, cache, or otherwise persist the malicious value.
5. Trigger or wait for a victim user to view the poisoned page or administrative interface.
6. Execute JavaScript in the victim's browser under the trusted site origin.
7. Use the victim's session and privileges to read data, alter content, create persistence, redirect traffic, or perform privileged actions.
8. Remove or obfuscate the injected payload to reduce forensic visibility, if the attacker has gained sufficient access.

How to detect it

Investigate both attempted payload injection and successful post-exploitation activity. Review HTTP access logs, WAF alerts, reverse-proxy logs, application request logs, CMS/plugin audit logs, content revision history, cache storage, database-backed content fields, administrative action logs, authentication logs, and CDN logs for encoded or raw script payloads. Focus on requests containing HTML tags, JavaScript event handlers, URI schemes such as javascript:, encoded angle brackets, or browser API calls submitted to content, configuration, cache, preview, or administrative endpoints. For successful exploitation, look for unusual administrator actions shortly after viewing suspicious content, such as new user creation, role changes, template edits, plugin installation, redirect insertion, JavaScript include changes, unexpected webroot file writes, or mass content edits. Correlate suspicious payload submissions with later page views by privileged users from the same stored object or URL. Inspect stored content and caches directly because stored XSS may persist after the original request logs age out. If a payload executed, browser-side evidence may be limited, so prioritize server-side artifacts showing attacker-controlled script storage and subsequent privileged state-changing requests.

• <script
• %3Cscript
• &lt;script
• </script>
• %3C%2Fscript%3E
• onerror=
• onload=
• onclick=
• onmouseover=
• javascript:
• data:text/html
• document.cookie
• document.domain
• localStorage
• sessionStorage
• XMLHttpRequest
• fetch(
• new Image(
• eval(
• atob(
• String.fromCharCode
• /wp-content/plugins/litespeed-cache/
• litespeed-cache
• craftcms/cms
• a54e725a3ad01da409d466e30369855642845a41

What your security team should do

• Prioritize remediation for internet-facing websites and administrative portals because exploitation is weaponized and the EPSS score indicates elevated exploitation probability.
• Resolve the product-mapping discrepancy by checking deployed assets for both the described LiteSpeed Cache exposure and the listed craftcms/cms fixed commit before closing the finding.
• Upgrade affected instances to a fixed version or, for craftcms/cms Git deployments, to commit a54e725a3ad01da409d466e30369855642845a41 or later.
• Purge all application, CDN, page, and object caches after patching to remove any stored malicious payloads.
• Search web logs, application logs, CMS audit logs, database-backed content, template fields, cache entries, and admin activity logs for script-bearing payloads submitted since publication.
• Review administrator account activity, newly created users, content modifications, plugin/theme/template changes, and unexpected redirects for signs of post-XSS abuse.
• Temporarily tighten WAF rules and input validation for HTML/script-bearing input where business functionality permits.
• Deploy or strengthen Content Security Policy, secure cookie attributes, CSRF protections, and privileged-action reauthentication to reduce impact of future XSS flaws.