Panellicense

CVE-2026-84761: the LiteSpeed Cache for WordPress SSRF fix

An unauthenticated SSRF in LiteSpeed Cache for WordPress below v7.9.1 hits sites behind QUIC.cloud with client-IP restoration off. Patch and exposure check.

LSAll LiteSpeed articlesNews & changelogs4 min readUpdated 2026-09-11
litespeedlscachewordpresscvesecurityquic.cloud
schema: TechArticleschema: FAQPageschema: BreadcrumbList

CVE-2026-84761 is a server-side request forgery (SSRF) vulnerability in LiteSpeed Cache for WordPress (LSCWP), the plugin bundled with most LiteSpeed-on-cPanel builds. LiteSpeed disclosed it on 2 September 2026 and shipped the fix in v7.9.1, released the day before. Patchstack reported the bug and rates it 7.2 (High) on CVSS 3.1 — AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N. No authentication or user interaction is required.

If you run LSCWP fleet-wide across a hosting stack, this is a same-day patch, not a next-maintenance-window one — but the exposure is narrower than the CVSS score alone suggests, and worth understanding before you page anyone.

Who is actually exposed

Exploitation needs both of the following true at once:

  1. The site is served through QUIC.cloud CDN.
  2. The origin server has "Use Client IP in Header" set to No in LiteSpeed Web Server, so the real visitor IP is never restored from the CDN's forwarded header.

Sites that don't sit behind QUIC.cloud aren't affected by this specific flaw, regardless of LSCWP version. Sites behind QUIC.cloud with client-IP restoration already on (the default LiteSpeed recommends when connecting QUIC.cloud to LSCache) are also out of scope. It's the combination of "behind the CDN" plus "IP restoration off" that opens the hole.

Where both conditions hold, an unauthenticated attacker can make the WordPress origin issue server-side requests to internal or otherwise unreachable network locations and read the full response back — the classic SSRF outcome of exposing internal services, metadata endpoints, or anything else on the server's private network path that a public request could never reach directly.

The fix

Update LSCWP to v7.9.1 or later from the WordPress plugin repository. There's no config migration and no cache-warming penalty — the patch closes the request-forwarding path without touching cache behaviour.

wp plugin update litespeed-cache --version=7.9.1

For a fleet, push it the same way you'd push any WordPress plugin update at scale — WP-CLI in a loop over wp_users document roots, or through Softaculous's auto-upgrade policy if the sites were provisioned through it. Neither path needs downtime.

Then, independent of the patch, check the second condition:

# on the LiteSpeed Web Server admin console, or via httpd config:
grep -i "clientip" /usr/local/lsws/conf/httpd_config.conf

If Use Client IP in Header is No and the server sits behind QUIC.cloud, turn it on. It doesn't just close this CVE's second precondition — real visitor IPs matter for ModSecurity and WAF rules, rate limiting, and access logs generally. A server that can't see real client IPs behind a CDN has a logging and security gap independent of any single plugin bug.

Next steps

Is CVE-2026-84761 exploitable without QUIC.cloud?+
No. The vulnerability requires the site to be served through QUIC.cloud CDN with LiteSpeed Web Server's client-IP restoration disabled. Sites on Cloudflare, BunnyCDN, or no CDN at all aren't affected by this specific flaw.
What LSCWP versions are affected?+
All versions prior to 7.9.1. Update to 7.9.1 or later to close the vulnerability.
Do I need to change WordPress or database settings to fix this?+
No. The fix is a plugin update plus, where applicable, enabling 'Use Client IP in Header' in LiteSpeed Web Server's config. No wp-config.php or database changes are involved.
Does this affect OpenLiteSpeed installs?+
The vulnerability is in the LSCWP plugin itself, so any WordPress site running it is affected regardless of whether the origin is LSWS or OpenLiteSpeed. The client-IP header setting is LSWS-specific; check your OLS vhost config for the equivalent proxy header handling if you're behind QUIC.cloud on OpenLiteSpeed.
Was this vulnerability exploited before the patch shipped?+
LiteSpeed's advisory and Patchstack's report don't cite in-the-wild exploitation prior to disclosure. Treat the same-day patch as precautionary hardening, not incident response, but don't delay it — the SSRF is unauthenticated and the CDN configuration it targets is common.

Related articles

All LiteSpeed →All news & changelogs →
how to
Enable LSCache for WordPress on a cPanel server
Turn on LSCache for every WordPress account on a cPanel server in one WHM action, then verify cache hits and fix the three configurations that catch most operators out.
7 min read
how to
Configure the LiteSpeed crawler to pre-warm LSCache
Pre-warm LSCache with the LSCWP crawler so the first visitor hits a cached page — covers the server-side allow flag, per-site sitemap config, LVE limits, and the four failures that quietly stop the crawler.
8 min read
how to
LiteSpeed ESI hole-punching for WooCommerce carts
Cache the full page for everyone while keeping the WooCommerce cart, "Hi, name" greeting, and nonce fields live — set up ESI blocks in LiteSpeed Cache the right way.
7 min read
how to
Set up LSMCD as a WordPress object cache on cPanel
LSMCD is LiteSpeed's drop-in memcached and Redis replacement, tuned to feed LSCache ESI blocks and act as a WordPress object cache. Install, secure with SASL, and wire WP-LSCache to it on cPanel.
11 min read
how to
Connect QUIC.cloud CDN to LSCache on a cPanel server
Wire QUIC.cloud's edge CDN into a cPanel server running LSCache — domain linking, CNAME setup, image optimization quotas, and verifying edge hits in under 20 minutes.
9 min read
troubleshoot
Fix LSCache showing disabled in LiteSpeed Cache for WordPress
Why LSCWP shows 'disabled' — advanced-cache.php conflicts, server-level LSCache off, OLS vs LSWS config — and the exact toggles that re-enable caching.
4 min read
Switch in an afternoon

Switch from your current reseller — free.

We migrate active cPanel, Plesk, LiteSpeed and CloudLinux licenses from any reseller. We prorate the first month so you never pay twice, and your customers see zero downtime during the swap.