PHP2Shell, Node2Shell, HTTP2Shell : la faille ne concerne plus seulement PHP

Article rédigé le 24 octobre 2026, à partir des avis publiés jusqu'à cette date. La situation évolue vite : vérifiez les avis officiels cités en fin d'article avant d'agir.

En quelques jours, deux noms ont envahi les fils de sécurité : PHP2Shell et Node2Shell, rebaptisée par certains HTTP2Shell. Le premier concerne le cœur de PHP. Le second est parti de Node.js, puis s'est révélé toucher bien plus large. Message à retenir : le risque ne concerne plus seulement les sites en PHP, mais potentiellement tous les sites et services qui traitent des requêtes HTTP. Voici ce que l'on sait, ce qui reste incertain et ce qu'il faut faire.

1. PHP2Shell : deux failles dans le cœur de PHP

PHP2Shell regroupe deux vulnérabilités du noyau de PHP, toutes deux notées 9,2 sur l'échelle CVSS v4.0 :

• CVE-2026-109618 : une erreur de mémoire insuffisante laisse les données d'une requête dans un état partiellement initialisé, que PHP traite ensuite comme valide à l'arrêt ;
• CVE-2026-109619 : un état global lié à une requête survit après la libération de sa mémoire, et une requête suivante sur le même processus le lit (utilisation après libération). Cette faille peut aussi faire fuiter la mémoire d'un processus PHP, avec le risque d'exposer des mots de passe, jetons ou clés d'API.

Les failles sont dans PHP lui-même : une application peut être touchée même si son code est irréprochable. Les déploiements web concernés incluent PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed. D'après PHP, l'urgence est maximale pour Apache mod_php, et PHP-FPM doit aussi être corrigé. Des exécutions de code à distance sans authentification ont été démontrées sur des CMS très répandus comme WordPress ou Drupal, et des codes d'exploitation publics circulent sur GitHub. Cloudflare a signalé du trafic d'attaque.

Versions corrigées de PHP

Les versions 8.1 et antérieures ne sont plus supportées officiellement : PHP n'a fourni que des correctifs limités pour certaines (7.4, 8.0, 8.1). Selon les données de l'éditeur Qualys, une grande majorité des installations PHP identifiées tournent encore sur des branches en fin de vie. Les paquets des distributions (Debian, Ubuntu, Red Hat…) peuvent corriger la faille sans changer le numéro de version : consultez l'avis de votre distribution plutôt que de vous fier au seul numéro.

2. Node2Shell : une faille dans le décodeur Brotli

Le second nom correspond à CVE-2026-111497 (CVSS 9,2), une écriture hors limites dans le décodeur Brotli, un algorithme de compression utilisé sur le web. Elle a d'abord été présentée comme une faille de Node.js (« Node2Shell »), car Node.js embarque ce décodeur. Elle serait due, d'après les analyses publiées, à une erreur de gestion dans la fonction qui lit les blocs d'un flux compressé : un flux spécialement construit peut provoquer une corruption mémoire, un plantage ou, potentiellement, une exécution de code.

Point important : Node.js ne décompresse pas du Brotli tout seul. Une application n'est exposée que si son code ou une bibliothèque décompresse des données contrôlées par un attaquant. D'après les analyses publiées, cela inclut notamment :

• une application Express 5 qui utilise express.json(), exposée par défaut selon l'analyse de Brandefense, car son analyseur de corps décode Content-Encoding: br ;
• des appels fetch() côté serveur qui reçoivent une réponse compressée en Brotli (webhooks, aperçus de liens, appels à des API tierces).

Versions corrigées de Node.js

• Node.js 26.x : 26.12.1
• Node.js 24.x : 24.22.1
• Node.js 22.x : 22.23.4
• Les lignes plus anciennes (20.x…) ou non maintenues : aucun correctif d'après les sources consultées ; considérez-les comme exposées et planifiez la migration.

3. HTTP2Shell : pourquoi le risque s'élargit

Le nom HTTP2Shell ne désigne pas une seconde faille : c'est la même CVE, rebaptisée quand on a compris que le défaut se trouvait dans la bibliothèque Brotli elle-même, utilisée bien au-delà de Node.js. Les avis publiés mentionnent notamment :

• la bibliothèque Google Brotli (versions 1.0.3 à 1.2.0, corrigées en 1.0.10, 1.1.1 et 1.2.1) ;
• les paquets Python Brotli et brotlicffi (corrigés en 1.2.1 et 1.2.1.0), que des clients comme urllib3, requests, httpx, aiohttp ou Scrapy utilisent automatiquement lorsqu'ils sont installés ;
• Bun (corrigé en 1.4.4) ;
• les proxys Envoy et Istio, qui ont publié des versions corrigées ;
• curl et ses dérivés, lorsqu'ils s'appuient sur une version vulnérable de Brotli, y compris dans des copies embarquées qui nécessitent de reconstruire l'application.

Selon Aikido, Apache et Nginx ne décodent pas le Brotli par défaut. Le risque est bidirectionnel :

• entrant : un client malveillant envoie une requête avec Content-Encoding: br à un serveur qui la décompresse ;
• sortant : votre application appelle un serveur contrôlé par un attaquant qui lui renvoie une réponse Brotli piégée.

Autrement dit : quel que soit le langage ou le framework, tout service qui décompresse du Brotli venant de l'extérieur doit être examiné.

4. Ce qui reste incertain

• L'exploitation de HTTP2Shell. Au 23 octobre, la CVE ne figurait pas dans le catalogue des vulnérabilités exploitées de la CISA. Des chercheurs affirment avoir obtenu une exécution de code sur Node.js, mais les codes publics ne le démontrent pas tous : certains ne provoquent qu'un plantage, et les affirmations sont contestées. Considérez le risque comme sérieux sans l'assimiler à une exploitation généralisée.
• Les scanners. Selon Aikido, certains outils (pip-audit, Dependabot, Safety) pouvaient ne pas signaler les paquets Python concernés au 23 octobre. Un résultat « rien à signaler » ne prouve pas que vous êtes à l'abri.
• Les chiffres et les dates. Les sources ne sont pas toutes d'accord sur le détail (heures de publication, versions exactes). Référez-vous aux avis officiels.

5. Plan d'action en quatre étapes

Aujourd'hui

1. Inventoriez : quelles versions de PHP, de Node.js, de Python et de proxys tournent en production, y compris dans les conteneurs et les images de base ?
2. Mettez à jour PHP vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou installez le paquet corrigé de votre distribution, puis redémarrez PHP-FPM ou Apache. Priorité aux serveurs Apache mod_php exposés à Internet.
3. Mettez à jour Node.js vers 22.23.4, 24.22.1 ou 26.12.1, reconstruisez vos images et redéployez.

Si vous ne pouvez pas mettre à jour immédiatement

• PHP : PHP recommande de désactiver le suivi de la progression des téléversements (session.upload_progress.enabled=0) et de redémarrer les processus, et de limiter la taille des requêtes et des envois multipart au niveau du proxy. Ces mesures réduisent l'exposition mais ne remplacent pas la mise à jour.
• Brotli entrant : refusez les requêtes dont l'en-tête Content-Encoding contient br, au niveau du proxy ou d'un middleware, avant tout décodage. Sous Express, l'option express.json({ inflate: false }) bloque aussi la décompression, mais rejette également les corps gzip : testez vos clients.
• Brotli sortant : retirez br de Accept-Encoding et refusez les réponses Brotli avant décompression ; modifier seulement l'en-tête ne suffit pas, car un serveur malveillant peut quand même répondre en Brotli.
• Python : mettez à jour Brotli et brotlicffi vers 1.2.1 ou désinstallez-les si vous n'en avez pas besoin : les clients HTTP retombent alors sur gzip et deflate.

Les jours suivants

• Cherchez dans votre code les usages de express.json, bodyParser, createBrotliDecompress et les appels fetch vers l'extérieur.
• Exécutez PHP et Node.js avec des comptes sans privilèges et gardez les secrets hors de l'environnement des processus : si la mémoire fuit, il y en aura moins à voler.
• Un pare-feu applicatif (WAF) ajoute une couche de protection, mais ne remplace jamais le correctif.

Si vous êtes exposé depuis le 20 octobre

Surveillez les fichiers PHP ou JavaScript récemment modifiés ou ajoutés, les comptes administrateurs créés sans raison, les processus inhabituels, les connexions sortantes suspectes et les pics de requêtes anormales. En cas de doute, faites tourner les secrets (clés d'API, mots de passe de base de données, jetons) après avoir corrigé la faille. Nos bonnes pratiques de cybersécurité détaillent la démarche générale.

6. Un rappel : la chaîne logicielle est un risque à part entière

Ces failles rappellent que le danger ne vient pas seulement du code que vous écrivez, mais aussi du runtime, des bibliothèques et des images de base. Nous avions déjà vu la même logique avec la faille Axios et la sécurisation de npm. Gardez PHP à jour — notre article sur PHP 8.5 rappelle pourquoi il vaut mieux rester sur les versions récentes — et automatisez la détection des versions obsolètes dans vos déploiements.

Et WordPress ? Une chaîne de failles sans lien avec les précédentes, nommée wp2shell et touchant le cœur de WordPress, avait été publiée en juillet 2026. Si vous gérez un site WordPress, vous avez donc deux raisons de vérifier vos mises à jour : le cœur du CMS et la version de PHP qui l'héberge.

Sources à consulter

• Qualys : PHP2Shell: Find, Mitigate, and Patch Now (20 octobre 2026)
• PHP2Shell : site de présentation des chercheurs (php2shell.com)
• Brandefense : Node2Shell: Fixed Node.js Versions and Check
• Aikido : Node2Shell Brotli vuln (CVE-2026-111497) evolves to HTTP2Shell
• Semgrep : Patch Your Node and Eat Your Brotli

Conclusion

PHP2Shell touche le cœur de PHP ; Node2Shell, devenue HTTP2Shell, touche une bibliothèque de compression utilisée par Node.js, Python, des proxys et des clients HTTP. Aucun langage n'est à l'abri par définition. La réponse est simple à énoncer, moins à exécuter : savoir ce qui tourne en production, mettre à jour PHP, Node.js et les bibliothèques Brotli, appliquer les mesures de contournement si le correctif attend, et surveiller les signes de compromission.