LiteSpeed Cache CVE-2026-3129

Two specific LiteSpeed Cache plugin configuration features must both be simultaneously enabled: 'Lazy Load Images' and 'Add Missing Sizes'. If either feature is disabled, the vulnerable regex code path in media.cls.php is not invoked and exploitation is not possible regardless of input. The attacker must authenticate to the WordPress instance with at minimum Author-level role; Subscriber-level or unauthenticated users cannot create or edit posts and therefore cannot inject the payload. The flaw is limited to self-hosted WordPress installations running LiteSpeed Cache version 7.7 or earlier - WordPress.com-hosted sites and installations without LiteSpeed Cache are unaffected. Limiting factors for defenders: the dual-feature requirement is a meaningful constraint since both features must be deliberately configured; Author-level access is not granted to arbitrary or unauthenticated users by default; exploitation requires the attacker to publish or update a post, generating a content audit trail in WordPress revision history.

The NVD-assigned CVSS 6.4 (Medium) captures a network-reachable, low-complexity, low-privilege attack with scope change but limited confidentiality and integrity impact. Real-world risk is moderate and highly deployment-dependent. The most significant constraining factor is the dual-feature requirement: both 'Lazy Load Images' and 'Add Missing Sizes' must be active simultaneously - without both, the vulnerable code path in media.cls.php is not triggered. Additionally, exploitation requires Author-level WordPress credentials, which meaningfully limits exposure on tightly controlled publishing platforms but represents a realistic threat on membership sites, multi-author blogs, or platforms where contributor accounts are granted to partially trusted users. No EPSS data was supplied in the source intelligence, precluding a quantitative exploitation probability assessment. The absence of a CISA KEV listing and publicly available exploit code indicates this has not been observed in mass exploitation campaigns at time of analysis; however, the low technical complexity once prerequisites are met - a simple crafted img tag post - means the barrier to exploitation is low for anyone who already holds Author access. Priority should be HIGH for WordPress sites with untrusted contributors and both features enabled; LOW for single-author or internally-controlled installations.

An attacker with Author-level credentials to a target WordPress site creates or edits a post containing a crafted img tag - for example, one with a malformed width or height attribute value that embeds a JavaScript event handler - which bypasses the flawed regex in media.cls.php and is stored in the WordPress database. When an administrator, editor, or logged-in user subsequently visits the page containing the injected content, the stored script executes automatically in their browser, potentially exfiltrating their WordPress session cookie to an attacker-controlled server and allowing full account takeover at the victim's privilege level. No publicly available exploit code has been identified at time of analysis, though the technical simplicity of crafting the bypass once the code path is understood reduces the effort required.