LiteSpeed Cache stored XSS (CVE-2026-113499 and 113500): a comment that runs in the admin’s browser

LiteSpeed Cache does more than cache pages; it rewrites and optimizes the HTML it serves. Two of its optimization routines were meant to act only on stylesheet content, but in versions before 7.9.2 they ran over the whole rendered page. In the course of rewriting, each could remove a character that was holding an HTML attribute closed — a quote, in the CDN inline-CSS rewriting routine behind CVE-2026-113499; the markup that closes an attribute, in the font-display optimization behind CVE-2026-113500. On its own that is a cosmetic bug. It becomes a security flaw because of what else is on the page.

A WordPress comment carries an author name, and many themes print that name into the page. If the theme prints it without escaping — a known weakness in some themes, not in LiteSpeed Cache itself — then an attacker can put HTML-significant characters in the name field of a comment. Normally the surrounding markup keeps that inert. But once LiteSpeed’s optimizer has stripped the character that closed a nearby attribute, the attacker’s crafted name is no longer trapped inside a quoted value: it can break out and introduce new attributes, including event handlers such as onmouseover or onload that run JavaScript. The result is stored cross-site scripting — stored because the comment is saved and served to everyone, and because the mangled page is then cached and served again.

The person who triggers it needs no account: anyone who can get a comment published can do it. The person who is attacked is whoever views the page, and the high-value target is a logged-in administrator, whose browser would run the injected script with their session — enough to create a new administrator, plant a backdoor plugin, or change site settings. That chain is why an XSS flaw that depends on a few conditions is still rated High. The third flaw disclosed in the same release, CVE-2026-113501, is unrelated and much milder: a Subscriber-level user can dismiss administrative notices the plugin marks as non-dismissible, including a warning that sensitive files may be exposed, which could keep an owner from seeing a problem but does not itself run code or take over an account.

Figure 1 · CVE-2026-113499 and 113500 at a glance

Three conditions must all hold — but the install base is seven million.

Question	What the advisories say	What to do
Severity	Two unauthenticated stored XSS flaws, CVSS 3.1 7.5 each	Update LiteSpeed Cache, then purge the cache
Patch	LiteSpeed Cache 7.9.2, released 20 October 2026	Update, then run Purge All
Who can use it	Anyone whose comment is published; no account needed	Moderate comments if you cannot update yet
When it bites	Only with CDN image mapping or Font Display on, and an unescaped name	Check both settings; the two flaws are independent
Impact	Script runs in a viewer’s browser, an admin’s included	Review comments and admins on an exposed site
Also fixed	CVE-2026-113501, a Subscriber notice-dismissal, low severity	7.9.2 closes it too

In short: if your sites keep comments closed or always moderated, or your theme escapes commenter names, or you do not run the CDN image-mapping and font-display options, you were most likely never exposed — and updating is simple hygiene. If a site does take open comments and has one of those optimization options on, treat it as exposed, update and purge first, then review recent comments and your administrators. The two flaws are independent, so a site can be exposed through one option and not the other; check both.

1. 01

   Update the plugin

   From the dashboard, Plugins → Installed Plugins → LiteSpeed Cache → Update now, or across sites with WP-CLI:

   WP-CLI

   $ wp plugin update litespeed-cache
   $ wp plugin get litespeed-cache --field=version

   Confirm the installed version reads 7.9.2 or newer. The vendor shipped 7.9.2 to the WordPress repository on 20 October and to the LiteSpeed control-panel plugin list on 23 October.

2. 02

   Purge the full cache

   So any page cached with injected or corrupted markup is regenerated from the fixed code:

   WP-CLI

   $ wp litespeed-purge all

   From the dashboard this is LiteSpeed Cache → Toolbox → Purge → Purge All. If the site also sits behind a CDN or an edge cache such as QUIC.cloud, purge that layer too, or the old page can persist at the edge.

3. 03

   Check the two optimization settings

   Confirm what was enabled, so you know whether the site met the conditions and how closely to review comments:

   WP-CLI

   $ wp litespeed-option get optm-css_font_display
   $ wp litespeed-option get cdn

   A value of 1 or a non-empty setting means that feature was active. You do not need to disable them after updating — 7.9.2 makes them safe — but knowing what was on tells you whether to treat the site as having been exposed.

Remove the malicious comment and purge the cache again so the clean page is served. If you also find a new administrator, a backdoor plugin, or settings you did not change, the incident went beyond a single comment and the site should be treated as compromised: the cleanup guides below are the next step. If the only finding is the comment itself and nothing in the administrator or plugin review looks wrong, deleting the comment and purging is enough.

1. 01

   Update LiteSpeed Cache to 7.9.2 everywhere

   On every site that runs it, update through the dashboard or wp plugin update litespeed-cache and confirm the version reads 7.9.2 or newer. This replaces the rewriting routines the XSS depends on.

2. 02

   Purge the full cache, and the edge

   Run Purge All (or wp litespeed-purge all) so pages cached with corrupted markup are regenerated, and purge any CDN or QUIC.cloud layer in front of the site so an old copy does not persist at the edge.

3. 03

   Decide how exposed the site was

   Check whether comments are open and unmoderated, whether the theme escapes author names, and whether CDN image mapping or font-display optimization was on. A site meeting all the conditions should have its recent comments and administrators reviewed; a site meeting none was not exposed.

4. 04

   If you cannot update immediately, moderate comments

   Turn on Settings → Discussion → “Comment must be manually approved” so nothing reaches a page unreviewed. This is the vendor’s interim workaround; it holds the stored vector shut until the update is applied, but it is not a substitute for updating.

5. 05

   Review comments and admins on exposed sites

   Look for comment author names containing markup, and for administrators, plugins or settings that changed around the exposure window. Remove the payload, and if anything else turns up, treat it as a site compromise and move to cleanup.

This advisory is based on the WPScan vulnerability records for CVE-2026-113499, CVE-2026-113500 and CVE-2026-113501, published 23 October 2026, the CVE records, and LiteSpeed Technologies’ own advisory of 23 October, which names the exact settings that make each XSS flaw reachable and gives comment moderation as the interim workaround. The mechanism, the affected and fixed versions, the CVSS ratings, the conditions and the researcher credits are taken from those. The seven-million installed-base figure is WordPress.org’s active-installations estimate. No exploitation in the wild has been reported, and no proof of concept is reproduced here; WPScan has said it will publish its proof of concept on 22 November 2026.