CVE-2026-3129 in Cache Plugin
Summary
by MITRE • 08/28/2026
The LiteSpeed Cache plugin for WordPress is vulnerable to Stored Cross-Site Scripting via crafted `<img>` tag attributes in all versions up to, and including, 7.7. This is due to a flawed regular expression that is used to strip `width` and `height` attributes from images when the "Lazy Load Images" and "Add Missing Sizes" features are enabled. This makes it possible for authenticated attackers, with Author-level access and above, to inject arbitrary web scripts in pages that execute whenever a user accesses an injected page.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The LiteSpeed Cache plugin is a widely utilized performance optimization tool for WordPress environments, designed to enhance site speed through features such as caching, image lazy loading, and asset minification. Within versions up to 7.7 inclusive, the implementation of the Lazy Load Images feature contains a critical input validation flaw that allows for Stored Cross-Site Scripting attacks. This vulnerability arises from an insufficient sanitization mechanism applied when processing HTML content during the optimization process. Specifically, the plugin employs a regular expression intended to strip width and height attributes from image tags to standardize dimensions or remove potentially conflicting styles. However, this regex pattern is flawed in its construction, failing to properly escape or neutralize special characters within attribute values that are not strictly numeric.
The technical root cause lies in the logic used by the Add Missing Sizes feature when it interacts with user-generated content. When an authenticated attacker with Author-level access or higher uploads media or edits posts containing crafted image tags, they can inject malicious JavaScript payloads disguised as malformed width or height attributes. Because the regular expression fails to validate that these attributes contain only valid numeric data, it inadvertently preserves parts of the injected payload while stripping others. This results in a situation where arbitrary web scripts are embedded directly into the stored content within the WordPress database. The vulnerability is classified under CWE-79, which covers Improper Neutralization of Input During Web Page Generation known as Cross-site Scripting, specifically highlighting the failure to sanitize user-supplied input before storing it for later use.
The operational impact of this Stored XSS vulnerability is significant because the malicious script persists in the database and executes automatically whenever a victim visits any page containing the compromised content. Unlike reflected XSS which requires tricking a user into clicking a specific link, stored XSS ensures that every visitor to the affected pages becomes a potential target. Attackers can leverage this capability to steal session cookies, hijack administrative accounts if an administrator views the infected post, or redirect users to phishing sites. The requirement for Author-level access means that while it is not trivially exploitable by unauthenticated outsiders, it poses a severe risk in collaborative environments where multiple contributors have elevated privileges. This aligns with MITRE ATT&CK technique T1059, Command and Scripting Interpreter, as the attacker uses browser-based scripting to execute unauthorized actions on behalf of victims.
Mitigation strategies for this vulnerability involve immediate updates and configuration adjustments. The most effective remediation is to upgrade the LiteSpeed Cache plugin to a version later than 7.7 where the regular expression has been corrected to strictly enforce numeric-only validation for width and height attributes, or to properly encode output when rendering these values. Administrators should also audit existing content for any injected scripts if an update cannot be applied immediately. Furthermore, implementing strict Content Security Policy headers can help mitigate the impact of successful XSS attempts by restricting the sources from which scripts are allowed to execute. Regular security audits and limiting contributor privileges to only those who absolutely require them will further reduce the attack surface associated with this type of vulnerability.