LiteSpeed Cache : deux failles XSS sans compte, correctif en 7.9.2

WPScan a publié le 21 octobre 2026 deux failles XSS stockées dans LiteSpeed Cache, CVE-2026-113499 et CVE-2026-113500, notées 7,5 (élevée). Un visiteur sans compte peut, par un simple commentaire publié, faire exécuter du JavaScript dans le navigateur de vos visiteurs, administrateurs compris, à condition que l’un de deux réglages d’optimisation soit actif. Voici quels sites sont concernés, comment savoir si les vôtres le sont et quoi faire, la version 7.9.2 corrigeant les deux failles.

Ce qui s’est passé

Les deux failles ont été trouvées par le chercheur Jakub Herman et coordonnées par WPScan, qui a réservé leurs identifiants CVE le 20 octobre à 11 h 59 (heure de Paris). Le même jour, LiteSpeed Technologies a publié la version 7.9.2 de l’extension. Son journal des modifications ne cite pas les CVE mais mentionne, entre autres durcissements, la prévention d’une injection HTML pendant la réécriture des adresses dans le CSS en ligne (module CDN) et la protection des limites HTML lors de la réécriture des ressources (module d’optimisation).

WPScan a mis ses deux avis en ligne le 21 octobre. Les fiches CVE ont été publiées le 23 octobre à 8 h, reprises le jour même par la base américaine NVD et par Patchstack, qui classe la faille en priorité élevée. Le 23 octobre à 12 h 37, l’analyse de la CISA (programme Vulnrichment) indiquait une exploitation « none » : aucune attaque connue à cette date. Au moment où nous écrivons, aucun éditeur de sécurité n’a signalé d’exploitation, et WPScan retient la preuve de concept jusqu’au 22 novembre 2026 « pour laisser aux utilisateurs le temps de mettre à jour ».

La même version 7.9.2 corrige une troisième faille, CVE-2026-113501 (3,1, faible) : un abonné connecté pouvait masquer des avertissements que l’extension présente comme non masquables, dont celui qui signale des fichiers sensibles accessibles publiquement. Patchstack a aussi publié le 22 octobre une fuite de données sensibles (CVE-2026-114190, 5,9) déjà corrigée en 7.9.1.

Qui est concerné

LiteSpeed Cache compte plus de 7 millions d’installations actives (wordpress.org). WPScan considère comme vulnérables toutes les versions antérieures à 7.9.2. Mais un site n’est exposé que si trois conditions sont réunies : les commentaires sont ouverts, le commentaire de l’attaquant est publié, et le réglage concerné est actif.

Élément	CVE-2026-113499	CVE-2026-113500
Titre WPScan	XSS stockée sans compte via la réécriture CDN du CSS en ligne	XSS stockée sans compte via l’optimisation de l’affichage des polices
Réglage en cause	CDN, « Use CDN Mapping » avec « Include Images »	Optimisation de page, CSS, « Font Display Optimization »
Par défaut	Désactivé	Désactivé, mais activé par les préréglages Advanced (recommandé), Aggressive et Extreme
Versions touchées	Antérieures à 7.9.2	Antérieures à 7.9.2
Version corrigée	7.9.2 (20 octobre 2026)	7.9.2 (20 octobre 2026)
Note CVSS 3.1	7,5, élevée	7,5, élevée
Compte requis	Aucun, mais le commentaire doit être publié	Aucun, mais le commentaire doit être publié
Exploitation connue	Aucune signalée au 25 octobre	Aucune signalée au 25 octobre

Les réglages qui ouvrent la porte

Les avis de WPScan parlent seulement de « l’option concernée ». Le titre de chaque avis et le code de la version 7.9.1 permettent de la nommer. Pour CVE-2026-113500, c’est « Font Display Optimization » (onglet CSS des réglages d’optimisation de page), qui ajoute font-display: swap aux règles @font-face. Elle est désactivée par défaut, mais le préréglage « Advanced », que l’extension affiche comme recommandé, l’active, tout comme « Aggressive » et « Extreme ». Si vous avez appliqué l’un de ces préréglages, considérez votre site comme concerné. Dans le code publié sur wordpress.org, ce traitement de la page entière apparaît en version 7.8 (mars 2026) ; WPScan ne fait pas cette distinction.

Pour CVE-2026-113499, c’est la réécriture des adresses url() du CSS en ligne vers un CDN. Elle ne tourne que si « Use CDN Mapping » est activé avec une correspondance qui inclut les images. Aucun préréglage ne l’active : il faut l’avoir configurée vous-même, ce qui touche surtout les sites qui servent leurs médias depuis un CDN externe.

Comment fonctionne l’attaque

Pour accélérer l’affichage, LiteSpeed Cache retouche le code HTML de vos pages avant de l’envoyer : il ajoute une consigne aux déclarations de polices, il remplace l’adresse des images par celle du CDN. Ces retouches ne devraient viser que du CSS. Selon WPScan, elles s’appliquaient en fait à toute la page, commentaires compris. En réécrivant un passage qui ressemble à du CSS, l’extension supprime un guillemet ou la marque qui ferme un attribut HTML.

C’est là que le nom de l’auteur du commentaire entre en jeu. WordPress l’enregistre comme du texte, et il reste inoffensif tant que la page garde sa structure. Une fois l’attribut mal refermé, une partie de ce texte devient un nouvel attribut, par exemple un gestionnaire d’évènement comme onmouseover, que le navigateur exécute. La charge est stockée : chaque visiteur de la page la reçoit, et si la page est en cache, elle est servie telle quelle à tous. WPScan n’a pas publié le détail de la charge, et nous ne le ferons pas.

La note de 7,5 traduit ces limites : attaque sans compte et impact maximal, mais complexité élevée (il faut le bon réglage et un commentaire publié) et action d’une victime (visiter la page). Le commentaire est publié automatiquement si la modération est désactivée, ou si votre site approuve d’office les auteurs « ayant déjà un commentaire approuvé » : l’attaquant poste d’abord un message anodin, puis le piège. La version 7.9.2 limite l’optimisation des polices aux blocs <style> et fait la réécriture CDN en tenant compte de la structure HTML.

Pourquoi une XSS peut coûter tout le site

Le script injecté s’exécute dans le navigateur de la personne qui regarde la page, avec ses droits. Pour un visiteur anonyme, il peut rediriger vers un site frauduleux. Pour un administrateur connecté qui consulte son propre site, il peut envoyer à sa place des requêtes vers le tableau de bord : créer un compte administrateur, installer une extension, modifier un fichier. C’est ce qui rend une XSS stockée sans compte si sérieuse, comme l’explique notre article sur les failles XSS dans WordPress.

LiteSpeed Cache en a déjà fait l’expérience. En mai 2024, WPScan décrivait une vague d’attaques contre CVE-2023-40000, une autre XSS stockée sans compte : le JavaScript injecté créait des administrateurs nommés wpsupp-user ou wp-configuser. Notre article sur les failles d’élévation de privilèges de LiteSpeed Cache en 2024 revient sur cette année noire. En août 2026, CVE-2026-18978 permettait déjà une XSS sans compte par le contenu des commentaires, corrigée en 7.9.

Vérifier votre site

WPScan n’a publié ni indicateur de compromission ni adresse d’attaquant. Les vérifications ci-dessous découlent du mécanisme décrit. Commencez par la version et les deux réglages, avec WP-CLI :

wp plugin list --name=litespeed-cache --fields=name,version,status
wp litespeed-option get optm-css_font_display
wp litespeed-option get cdn
wp litespeed-option get 'cdn-mapping[inc_img][0]'

En version 7.9.2 ou plus récente, ces failles sont fermées. En version antérieure avec un des réglages actif, poursuivez :

• Les commentaires publiés récemment : wp comment list --status=approve --number=100 --fields=comment_ID,comment_date,comment_author,comment_author_url. Un nom d’auteur contenant des guillemets, des chevrons, du code ou des mots comme onmouseover= n’a rien à faire là.
• Les administrateurs : wp user list --role=administrator --fields=ID,user_login,user_email,user_registered. Un compte inconnu ou créé récemment est un signal d’alerte.
• Les mots de passe d’application : wp user application-password list <identifiant> pour chaque administrateur.
• Les extensions et fichiers : wp plugin list --fields=name,version,status, wp plugin verify-checksums --all, wp core verify-checksums et find wp-content -name "*.php" -mtime -60 -type f pour repérer les fichiers PHP modifiés ces 60 derniers jours.

Que faire maintenant

• Mettez à jour en 7.9.2 (Extensions, Extensions installées, ou wp plugin update litespeed-cache), puis videz tout le cache, y compris celui du CDN : wp litespeed-purge all.
• Si la mise à jour doit attendre, désactivez « Font Display Optimization » et la réécriture CDN, puis mettez les nouveaux commentaires en modération (Réglages, Discussion) jusqu’à la mise à jour.
• Supprimez les commentaires suspects repérés ci-dessus et décochez au besoin l’approbation automatique des auteurs déjà approuvés.
• Si un indice de compromission apparaît : supprimez les comptes inconnus, changez les mots de passe des administrateurs, révoquez les mots de passe d’application, renouvelez les clés de salage de wp-config.php (wp config shuffle-salts), analysez le site et restaurez une sauvegarde saine. Notre guide pour nettoyer un site WordPress piraté détaille chaque étape.

Réduire l’exposition la prochaine fois

Le correctif est sorti la veille des avis et un mois avant la preuve de concept annoncée : un site mis à jour dans les jours suivants a fermé la porte avant que le détail de l’attaque soit public. Quelques réflexes réduisent cette fenêtre :

• activer les mises à jour automatiques des extensions, au moins pour les versions de sécurité ;
• recevoir des alertes de vulnérabilités et suivre les mises à jour en attente sur tous vos sites ;
• limiter le nombre d’administrateurs et éviter de naviguer sur le site public avec ce compte quand un éditeur suffit (principe du moindre privilège) ;
• n’activer que les optimisations utiles, modérer les commentaires et garder des sauvegardes hors du serveur ;
• ajouter un pare-feu applicatif capable de correctifs virtuels : Patchstack indique avoir publié une règle pour cette faille (comparatif des WAF).

WP Masquerade Pro peut aider sur la surveillance, sans remplacer la mise à jour. Les alertes de vulnérabilités comparent chaque jour les versions installées des extensions de wordpress.org avec la base publique WPVulnerability.net et préviennent par e-mail : une version de LiteSpeed Cache antérieure à 7.9.2 y est signalée dès que la base référence ces failles. L’alerte ne sait pas si vos réglages vous exposent, elle porte sur la version.

Le journal d’activité enregistre, dès son activation, la création d’un utilisateur, un changement de rôle ou l’activation d’une extension : un administrateur créé par un script injecté y apparaît. Le contrôle d’intégrité ne porte que sur les fichiers du cœur de WordPress. L’espace membre rassemble les mises à jour en attente et les sites vulnérables de tous vos sites. Il alerte, il ne corrige pas et ce n’est pas un pare-feu. Pour le contexte, voici l’historique complet des failles de LiteSpeed Cache.

Sources

• cve.org : CVE-2026-113499 (23 octobre 2026) (lien externe, nouvel onglet)
• cve.org : CVE-2026-113500 (23 octobre 2026) (lien externe, nouvel onglet)
• wordpress.org : LiteSpeed Cache, journal des modifications (version 7.9.2 du 20 octobre 2026) (lien externe, nouvel onglet)

Autres sources consultées : autres fiches CVE, articles de la presse spécialisée, bases WPScan et Patchstack.