CVE-2026-18978: LiteSpeed Cache <= 7.8.1 - Unauthenticated Stored Cross-Site Scripting via Comment Content
The LiteSpeed Cache plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Comment Content in all versions up to, and including, 7.8.1 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. A comment payload crafted exclusively from decimal numeric character references (e.g. ", <, >) placed inside an allowed element such as <code> bypasses WordPress's wpkses sanitization, as kses does not treat a data-settings="..." substring within text content as an HTML attribute, allowing the malicious payload to reach the vulnerable function. For this to be exploitable, the site must allow users with previously approved comments to write new comments, and the requirenameemail setting must be disabled.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
LiteSpeed Cache (WordPress plugin)to a version that resolves this vulnerability.Fixed in 7.8.1 - Upgrade
Upgrade
LiteSpeed Cache (WordPress plugin)to a version that resolves this vulnerability.Patch LiteSpeed Cache <= 7.8.1 - Unauthenticated Stored Cross-Site Scripting via Comment Content - Configuration
To make the described exploit scenario non-exploitable, ensure the WordPress setting require_name_email is enabled (i.e., do not disable it).
WordPress require_name_email = disabled - Compensating control
Prevent untrusted users from posting comments by ensuring only appropriately authorized users can create/update comments (the issue requires that previously approved-comment users be able to write new comments).
Event History
Frequently Asked Questions
Which sites are exposed to exploitation?
Affected installations are LiteSpeed Cache versions through 7.8.1 where users with previously approved comments can submit new comments and WordPress's require_name_email setting is disabled.
What access does an attacker need?
No authentication or user interaction is required from the attacker. They need to be able to submit a crafted comment under the site's configuration conditions, using decimal numeric character references within an allowed element such as code.
What is the practical impact if exploitation succeeds?
The injected script is stored in a page and executes when another user accesses that page. This can expose or modify information in the affected user's browser session, reflected by the confidentiality and integrity impacts in the supplied vector.
What can be changed while an update is not available?
Enable the require_name_email setting and/or prevent users with previously approved comments from submitting new comments. Either change removes a stated condition required for exploitation.