Faille Brotli (HTTP2Shell) : votre site WordPress est-il exposé ?

Après PHP2Shell, voici HTTP2Shell, de son identifiant officiel CVE-2026-111497 (qu’est-ce qu’une CVE ?). Le nom trompe : la faille n’a rien à voir avec le protocole HTTP/2. Et contrairement à PHP2Shell, elle ne se trouve ni dans PHP ni dans WordPress. Elle touche Brotli, un format de compression des pages web, et plus précisément la bibliothèque qui décompresse ces données sur le serveur.

WordPress ne contient pas cette bibliothèque. Il peut pourtant s’en servir, sans le savoir, quand il va chercher une page sur un autre site. C’est par ce chemin qu’un attaquant peut l’atteindre.

Pourquoi un WordPress sans extension est concerné

Votre site ne fait pas que répondre à ses visiteurs. Il va aussi chercher des pages ailleurs : pour afficher l’aperçu d’une vidéo collée dans un article, pour lire un flux d’actualités, ou pour vérifier un ping. Un ping (pingback en anglais) est la notification automatique qu’un blog envoie à un autre quand il le cite. Avant de l’enregistrer, WordPress va lire la page d’où il vient, pour s’assurer qu’elle contient bien un lien vers vous.

Pour ces requêtes, WordPress passe par cURL, un outil installé sur le serveur, et lui confie la décompression des réponses. Quand cURL a été installé avec Brotli, il annonce qu’il accepte ce format et décode les réponses avec la bibliothèque Brotli du système.

L’attaque publiée tient en une seule demande, sans compte ni mot de passe. L’attaquant envoie au fichier xmlrpc.php de votre site un faux ping, qui prétend venir d’une page de son serveur. WordPress va lire cette page. Le serveur de l’attaquant répond avec des données compressées piégées, et la bibliothèque les décode avant que WordPress ne voie la réponse.

Dans une installation standard, XML-RPC et les pings sont actifs d’office. Un site resté sur les réglages d’origine remplit donc toutes les conditions du côté de WordPress, sauf si son hébergeur bloque xmlrpc.php. Le reste dépend du serveur : il doit avoir le droit d’aller chercher des pages ailleurs, et sa bibliothèque Brotli doit être une version touchée.

La version de WordPress affichée dans Outils, puis Santé du site, ne vous apprendra rien sur ce point : Brotli est installé et mis à jour à part, sur le serveur.

Ce que la faille Brotli permet vraiment

Des données compressées mal formées font écrire la bibliothèque en dehors de la zone de mémoire qui lui est réservée. Selon ce qu’elle écrase, le programme plante, laisse fuiter des informations ou exécute du code fourni par l’attaquant. Les versions touchées vont de la 1.0.3, sortie en 2018, à la 1.2.0 (avis du Centre canadien pour la cybersécurité). Les versions corrigées sont sorties le 21 octobre 2026 et Google a rendu la faille publique le lendemain, avec une note de gravité de 9,2 sur 10 (score CVSS).

• Faire planter PHP est facile, quelle que soit la version de PHP, tant que Brotli n’est pas corrigé. D’après un éditeur de sécurité spécialisé dans WordPress, une seule demande fait tomber un processus PHP, et quelques centaines suffisent à rendre un site indisponible (son analyse du 30 octobre, en anglais).
• Prendre la main sur le site est possible, mais l’attaque doit être taillée sur mesure. Les chercheurs d’un autre éditeur de sécurité ont exécuté du code sur un WordPress, sans compte, dans un laboratoire isolé qui reproduisait à l’identique l’environnement pour lequel l’attaque publiée a été écrite : Debian 13, Apache, PHP 8.3.36. Avec PHP 8.3.35, la même attaque n’a exécuté aucun code ; dans l’un des essais, elle a seulement fait planter PHP (leur analyse du 2 novembre, en anglais).

La version de PHP n’y est pour rien : une petite différence dans la façon dont PHP a été compilé suffit à faire échouer cette attaque-là, et une autre peut être préparée pour la 8.3.35. Ne changez pas de version de PHP à cause de cette faille.

Ces chercheurs jugent plausible qu’une attaque mise au point pour un serveur serve ensuite contre les sites qui partagent la même configuration. Ce point nous paraît important pour l’hébergement mutualisé, où de nombreux sites tournent sur le même serveur, avec la même installation de PHP.

Le 27 octobre, l’agence américaine de cybersécurité (CISA) a inscrit la faille sur sa liste des vulnérabilités exploitées, sans préciser quel logiciel ni quelle victime. Des sociétés de sécurité observaient encore des tentatives d’attaque le 2 novembre. À cette date, aucune attaque réussie contre un système en service n’avait été documentée publiquement, par WordPress ou autrement. La CISA ne publie pas ses éléments : l’absence de cas public ne prouve pas qu’il n’y en a pas eu.

Un hébergeur à jour pour PHP2Shell ne l’est pas forcément pour Brotli

Le 2 novembre, nous avons examiné l’hébergement mutualisé où tournent nos sites de test, chez un hébergeur connu en France. PHP y avait été recompilé le 21 octobre au soir, le jour des correctifs de PHP2Shell. La bibliothèque Brotli, elle, annonçait la version 1.0.6, et ses fichiers dataient du 10 février 2026. Red Hat a publié le correctif pour cette famille de systèmes le 26 octobre.

Sur ce même hébergement, nous avons demandé à WordPress 7.1.4 d’aller chercher une page de test publique. WordPress a annoncé qu’il acceptait le format Brotli, avec l’en-tête Accept-Encoding: deflate, gzip, br, et une réponse dans ce format a bien été décodée, par la bibliothèque datée de février.

Les deux failles se corrigent dans deux logiciels différents. Un PHP récent ne dit rien de l’état de Brotli : il faut poser la question.

La question à poser à votre hébergeur

Sur un hébergement mutualisé, la bibliothèque appartient au serveur et vous ne pouvez pas la remplacer vous-même. Copiez ce message dans une demande d’assistance, en indiquant l’adresse de votre site :

Bonjour, pour le site [adresse de votre site] : la bibliothèque Brotli utilisée par PHP (paquet brotli ou libbrotli du système, et toute autre copie chargée par PHP) a-t-elle reçu le correctif de la faille CVE-2026-111497 ? Si oui, à quelle date, et avec quelle version du paquet ? Le serveur web et les processus PHP ont-ils été redémarrés depuis cette mise à jour ?

La dernière question compte autant que la première : un programme déjà lancé garde en mémoire l’ancienne bibliothèque jusqu’à son redémarrage. Si l’hébergeur répond que la mise à jour n’est pas faite, demandez-lui une date et gardez les mesures d’attente décrites plus bas jusque-là. S’il ne répond pas, c’est une indication utile pour la prochaine faille, et pour le choix de votre prochain hébergeur.

Si vous administrez vous-même votre serveur, installez la mise à jour de sécurité de votre système, puis redémarrez les services. Le numéro de version ne suffit pas pour savoir si la bibliothèque est corrigée : les distributions Linux corrigent l’ancienne version sans la renuméroter. Comparez la révision complète du paquet, avec dpkg-query -W libbrotli1 sous Debian ou Ubuntu, ou rpm -qa '*brotli*' sous Red Hat et AlmaLinux.

Sources : les suivis de sécurité de Debian, d’Ubuntu et de Red Hat, en anglais. Sous Ubuntu 20.04, le correctif n’est fourni qu’avec l’abonnement Ubuntu Pro. Pour les autres systèmes, consultez l’avis de sécurité de leur éditeur. Sur CloudLinux, plusieurs copies de Brotli peuvent coexister, celle du système et celles livrées avec le serveur web ou avec PHP : chacune doit être à jour. Si votre site tourne dans un conteneur Docker, reconstruisez l’image en y installant la mise à jour du paquet libbrotli1, puis redéployez : au 30 octobre, l’image officielle wordpress:latest contenait encore la version vulnérable.

Fermer la voie d’attaque connue en attendant

En attendant la réponse de l’hébergeur, vous pouvez fermer la voie empruntée par l’attaque publiée. Ces mesures ne corrigent pas la faille : d’autres chemins mènent à la même bibliothèque, par exemple une extension qui va lire une adresse fournie par un visiteur.

Bloquer xmlrpc.php si rien ne s’en sert

Quelques outils ont encore besoin de ce fichier : Jetpack, par exemple, ou un logiciel qui publie sur le site depuis un ordinateur. Regardez si Jetpack figure dans vos extensions ; en cas de doute, posez la question à votre prestataire. Si vous n’en utilisez aucun, demandez à votre hébergeur de bloquer xmlrpc.php.

Sur un serveur Apache ou LiteSpeed, vous pouvez aussi le faire vous-même. Gardez d’abord une copie du fichier .htaccess, puis ajoutez ces trois lignes tout en haut, avant la ligne # BEGIN WordPress :

<Files xmlrpc.php>
Require all denied
</Files>

Si votre site affiche une erreur 500 juste après, remettez la copie et passez par votre hébergeur.

Pour contrôler le résultat, ouvrez l’adresse https://www.votre-site.fr/xmlrpc.php dans votre navigateur, avec le nom de votre site. Le message « XML-RPC server accepts POST requests only. » signifie que le fichier est ouvert. Une page « 403 Forbidden » ou une erreur 404 signifie qu’il est bloqué par le serveur. Notre analyse gratuite fait aussi ce contrôle, sans vous connecter à votre site, et indique si les pings sont ouverts.

Méfiez-vous des réglages au nom rassurant. L’option qui désactive l’authentification par XML-RPC, proposée par certaines extensions de sécurité, comme le filtre xmlrpc_enabled recopié dans de nombreux tutoriels, ne ferme que les fonctions protégées par un mot de passe (documentation du filtre, en anglais). Les pings n’en demandent aucun : ils continuent de passer.

Le réglage « Autoriser les notifications de lien » de la page Réglages, puis Commentaires, ne suffit pas non plus : il ne vaut que pour les publications à venir, et la page d’exemple créée à l’installation de WordPress garde ses pings ouverts.

Pour votre prestataire : un réglage qui laisse Jetpack fonctionner

Si le site a besoin de XML-RPC, ou pour couvrir aussi les autres chemins, ce petit fichier fait deux choses. Il retire de XML-RPC la seule fonction des pings, sans toucher à celles qu’utilise Jetpack. Et il empêche WordPress de demander des réponses en Brotli et de les faire décompresser, pour toutes ses requêtes, y compris celles des extensions qui passent par lui.

Il s’installe comme une extension « must-use », chargée d’office : un fichier PHP déposé dans le dossier wp-content/mu-plugins (à créer s’il n’existe pas), par exemple sous le nom attente-brotli.php.

<?php
/*
 * Plugin Name: Attente Brotli
 * Description: En attendant le correctif Brotli (CVE-2026-111497).
 */
add_filter( 'xmlrpc_methods', function ( $methods ) {
	unset( $methods['pingback.ping'], $methods['pingback.extensions.getPingbacks'] );
	return $methods;
} );
add_action( 'http_api_curl', function ( $handle ) {
	curl_setopt( $handle, CURLOPT_ENCODING, 'identity' );
	curl_setopt( $handle, CURLOPT_HTTP_CONTENT_DECODING, 0 );
}, 99 );

Nous l’avons essayé le 2 novembre sur l’hébergement de nos sites de test. La fonction des pings disparaît de XML-RPC, qui répond qu’elle n’existe pas. WordPress demande des réponses non compressées, et une réponse envoyée malgré tout en Brotli lui arrive telle quelle, sans passer par la bibliothèque. Une réponse compressée en gzip reste lisible, car WordPress la décompresse lui-même, et une requête ordinaire aboutit normalement. En contrepartie, votre site ne reçoit plus de pings. Retirez le fichier quand l’hébergeur a confirmé la mise à jour.

Questions fréquentes

Faut-il attendre une mise à jour de WordPress ?

Non. Elle ne corrigerait pas la faille : une nouvelle version de WordPress, d’une extension ou d’un thème ne touche pas à la bibliothèque du serveur. Gardez quand même WordPress à jour comme d’habitude : la version actuelle est la 7.1.4.

Mon hébergeur propose la compression Brotli pour accélérer mon site : faut-il la couper ?

Couper cette option ne protège pas votre site. Elle sert à compresser les pages envoyées à vos visiteurs, alors que la faille touche la décompression des données reçues par le serveur. Seule la mise à jour de la bibliothèque règle le problème.

Une extension de sécurité peut-elle arrêter l’attaque ?

Pas en reconnaissant les données piégées. La demande reçue par votre site ressemble à n’importe quel ping, et les données piégées arrivent ensuite, dans la réponse que votre serveur est allé chercher : la bibliothèque les décode avant que WordPress, et donc toute extension, ne les voie. Une extension peut en revanche fermer la porte d’entrée, ou empêcher WordPress de faire décompresser le Brotli, comme le réglage pour prestataire décrit plus haut.

Quel rapport avec PHP2Shell ?

Les deux failles PHP2Shell touchaient PHP lui-même et ont été corrigées le 21 octobre. HTTP2Shell touche une autre bibliothèque. Elles ont un point commun : dans les deux cas, la correction se fait sur le serveur, pas dans WordPress. Le suffixe « 2Shell » désigne une faille qui peut ouvrir à un attaquant l’accès au serveur.

Mon site a-t-il pu être attaqué ?

Les traces d’une tentative se trouvent surtout chez l’hébergeur : des processus PHP qui plantent ou restent bloqués, des erreurs 500 ou 503 passagères, des connexions inhabituelles du serveur vers l’extérieur. Des demandes sur xmlrpc.php ne suffisent pas à conclure : les robots y essaient des mots de passe sur presque tous les sites. Aucun de ces signes ne prouve une attaque réussie, et leur absence ne prouve pas le contraire. Si votre serveur a tardé à être corrigé, demandez à l’hébergeur de conserver ses journaux, et vérifiez qu’aucun fichier ni compte inconnu n’est apparu sur votre site. Les signes à chercher sont détaillés dans notre guide pour repérer un site piraté.