Failles PHP et Node.js d'octobre 2026 : ce qu'il faut faire
Par Maxime Vannier,
Le 21 octobre 2026, PHP a corrigé en urgence deux failles critiques, surnommées PHP2Shell, qui permettent de prendre la main sur un serveur web sans le moindre compte. Le même jour, Node.js publiait dix correctifs de sécurité. Si votre site, votre boutique, votre extranet ou un outil interne tourne sur l'un de ces deux moteurs, la mise à jour ne peut pas attendre la semaine prochaine.
Le 21 octobre, deux alertes le même jour
Mardi 20 octobre, le projet PHP annonce une version de sécurité « critique » pour le lendemain à 16 heures, heure de Paris. Le matin même, des détails avaient fuité sur un forum avant d'être retirés, et la publication, d'abord prévue pour le 22, a été avancée d'un jour. Le mercredi, vers 9 h 30, des hébergeurs signalent les premières tentatives d'attaque. Les correctifs sortent en milieu d'après-midi, un peu avant l'heure annoncée.
Ce jour-là, j'ai traité nos propres serveurs et, en parallèle, ceux de plusieurs clients, sur des environnements différents. D'abord, regarder les journaux à la recherche de signes d'attaque : il n'y en avait pas. Ensuite, appliquer les mesures temporaires en attendant les paquets corrigés, les installer dès leur publication, redémarrer les services, puis contrôler que chaque site répondait normalement. Tout était bouclé dans la même fin d'après-midi.
Le soir, j'ai profité de l'intervention pour faire le tour complet de nos serveurs, comme nous le recommandons à tous : système, base de données, bibliothèques utilisées par le site. Nous avons tout mis à jour, le système le soir même, les bibliothèques dans la nuit, après un essai sur une copie du site. Une alerte de ce niveau est le bon moment pour vérifier tout le reste, pas seulement le composant dont on parle.
PHP2Shell : deux failles au cœur de PHP
PHP fait tourner une grande partie du web. Selon W3Techs, il sert 69,3 % des sites dont le langage côté serveur est connu. WordPress, PrestaShop, Joomla, Drupal, Nextcloud, beaucoup d'extranets et bien des logiciels métier en ligne reposent sur lui.
Les deux failles portent les identifiants CVE-2026-109618 et CVE-2026-109619. Le projet PHP les note 9,2 sur 10, le NIST américain 9,8. Le surnom PHP2Shell vient des chercheurs qui les ont trouvées : le « shell », c'est l'accès en ligne de commande au serveur, exactement ce que cherche un attaquant.
Ce qu'un attaquant peut obtenir
La première faille se déclenche quand PHP manque de mémoire pendant qu'il lit un formulaire envoyé au serveur, typiquement un envoi de fichier. En provoquant cet épuisement à dessein, l'attaquant laisse PHP dans un état incohérent qu'il peut détourner. La seconde exploite des informations qu'une requête précédente a laissées en mémoire. Dans les deux cas, il n'a besoin ni de compte ni de mot de passe : une série de requêtes bien construites suffit, souvent plusieurs milliers, ce qu'un robot envoie sans effort.
Au bout, il peut exécuter des commandes sur le serveur avec les droits du site. Les chercheurs de Wiz ont aussi montré qu'on peut lire une partie de la mémoire du serveur, où traînent les données des autres visiteurs : mots de passe, jetons de connexion, clés d'accès à des services en ligne. Cette fuite ne demande même pas d'exécuter du code.
Pourquoi un WordPress à jour ne suffit pas
C'est le point le plus souvent mal compris. La faille n'est ni dans WordPress, ni dans PrestaShop, ni dans une extension : elle est dans PHP, le moteur qui exécute leur code. Un site WordPress parfaitement à jour, posé sur un PHP non corrigé, reste exposé.
L'équipe de Calif a démontré l'attaque sur WordPress, Drupal, Joomla, Magento, Nextcloud, phpMyAdmin et plusieurs autres logiciels. Le projet PrestaShop l'a rappelé le jour même à ses utilisateurs : inutile de se précipiter sur une mise à jour majeure de la boutique, c'est la version de PHP qu'il faut vérifier, et confirmer par écrit avec l'hébergeur. Si votre site est confié à un prestataire, c'est la première question à lui poser ; c'est aussi ce que couvre notre maintenance de site internet, serveur compris : nous administrons nous-mêmes les serveurs qui hébergent les sites.
Des failles trouvées avec l'aide de l'IA
Deux équipes ont trouvé ces failles chacune de son côté, cet été. Wiz dit s'être appuyé sur ses propres outils et sur des modèles d'intelligence artificielle ; Calif affirme n'avoir utilisé que des modèles accessibles au public. Un problème voisin avait pourtant été signalé dès 2020, puis retrouvé lors d'un audit du code de PHP en 2024, sans qu'on sache alors l'exploiter.
Des failles enfouies depuis des années dans un logiciel aussi examiné que PHP ont donc fini par être trouvées. Je m'attends à des alertes de ce genre plus fréquentes, et à un délai toujours plus court entre la publication d'un correctif et les premières attaques.
Chronologie : d'août au 21 octobre
Août et septembre. L'équipe de Calif découvre plusieurs chemins menant à une exécution de code et signale un premier bogue au projet PHP le 11 août. Wiz signale de son côté une faille le 24 août. Le correctif coordonné se prépare en septembre.
Mardi 20 octobre. Une publication sur Hacker News annonce deux failles critiques ; elle est retirée, mais des captures circulent. Dans la journée, PHP annonce sa version de sécurité pour le lendemain. Avant la divulgation, une vidéo de démonstration publiée par erreur circule elle aussi.
Mercredi 21 octobre, le matin. Cloudflare déploie des règles de protection pour tous ses clients vers 5 heures, heure de Paris. À 9 h 34, des hébergeurs partenaires de Patchstack signalent les premiers incidents.
Mercredi 21 octobre, l'après-midi. PHP publie les versions corrigées 8.2.35, 8.3.36, 8.4.27 et 8.5.12, entre 15 heures et 16 heures. Le CERT-FR publie son alerte CERTFR-2026-ALE-014. À la demande de l'ANSSI, le ministère de l'Intérieur met les sites des préfectures hors ligne par précaution ; des administrations des Pays-Bas et de Finlande font de même. Aucune intrusion n'a été signalée sur ces sites : c'est une mesure de prudence.
Mercredi 21 octobre, en fin de journée. Les distributions Linux, les images Docker officielles et les hébergeurs déploient les correctifs, chacun à son rythme.
Sur l'exploitation réelle, les sources divergent, et il vaut mieux le dire. Plusieurs sociétés de sécurité ont vu des tentatives dès le matin, avec un outil public servant à balayer Internet en masse. Le même jour, l'agence américaine CISA et le NCSC britannique n'avaient pas encore constaté d'exploitation, et Patchstack ne voyait vers 16 heures que des sondages, sans compromission prouvée. Personne ne publie à ce jour de nombre de serveurs compromis. En revanche, plus de cinq millions de serveurs PHP sont visibles depuis Internet, selon VirusTotal, cité par BleepingComputer : la cible est immense.
Votre site est-il concerné ?
Toute installation de PHP qui sert des pages web est concernée, quel que soit le logiciel qu'elle fait tourner, et quel que soit son mode de fonctionnement (PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed). Le risque est jugé le plus élevé avec mod_php. La vraie question n'est donc pas « mon site utilise-t-il PHP ? », mais « qui met à jour le PHP de mon site, et l'a-t-il fait ? ».
Site en hébergement mutualisé
Sur un hébergement mutualisé, c'est l'hébergeur qui gère PHP. OVHcloud a annoncé le 21 octobre une mise à jour automatique sur ses offres mutualisées, et Hostinger sur ses offres gérées. D'autres ont mis davantage de temps. Le bon réflexe, conseillé par le projet PrestaShop : demander à votre hébergeur une confirmation écrite que le correctif est appliqué, plutôt que de la supposer.
VPS, serveur dédié ou conteneur Docker
Là, personne ne le fera à votre place. OVHcloud le rappelle clairement : sur ses serveurs privés virtuels et ses serveurs dédiés, la mise à jour revient au client.
Il faut installer les paquets corrigés, puis redémarrer PHP-FPM ou Apache. Ce redémarrage est souvent oublié : sans lui, l'ancien code reste chargé en mémoire. Sur Debian, Ubuntu ou Red Hat, la version affichée par PHP ne change pas toujours après correction ; c'est le numéro du paquet qui fait foi.
Avec Docker, mettre à jour ne suffit pas : il faut reconstruire l'image sur une image de base corrigée et redéployer. Le 21 octobre, une étiquette générique comme php:8.2-fpm a continué de pointer quelques heures vers la version vulnérable ; mieux vaut viser la version exacte.
Pensez enfin aux équipements qui embarquent PHP dans leur interface d'administration : certains pare-feu d'entreprise et des serveurs NAS, par exemple. La correction vient alors du fabricant, et il faut aller la chercher.
Les anciennes versions de PHP
PHP 8.1 n'est plus maintenu depuis le 31 décembre 2025. Pour lui, comme pour 8.0 et 7.4, le projet n'a publié que du code source à recompiler, aucune version prête à installer. Or, selon W3Techs, 34,8 % des sites PHP tournent encore sur PHP 7 ou plus ancien.
Pour ces serveurs, les consignes sont nettes. La CISA recommande de les mettre hors ligne tant qu'ils ne sont pas corrigés ; le CERT-FR demande de les isoler et de migrer. Et PHP 8.2 sort à son tour du support le 31 décembre 2026 : un site en 8.2 est corrigé aujourd'hui, il ne le sera plus lors d'une alerte survenue après cette date. C'est le moment de planifier la migration, à froid, plutôt que de la subir.
Node.js : dix failles corrigées le même jour
Le même mercredi, Node.js publiait ses correctifs. Node.js, c'est le moteur qui fait tourner du JavaScript côté serveur : applications web, extranets, outils d'automatisation, et beaucoup d'outils qui servent à construire un site. Les versions 22.23.4, 24.22.1 et 26.12.1 corrigent, selon la publication de Node.js, dix failles, dont quatre jugées élevées, et toutes ne touchent pas les trois branches. Le calendrier tient du hasard : Node.js avait fixé sa date dès le 14 octobre, alors que celle de PHP a été avancée à cause d'une fuite.
La faille Brotli, la plus sérieuse
La faille CVE-2026-111497 touche le décodeur Brotli, un format de compression courant sur le web. Des données malformées y provoquent une écriture en dehors de la zone de mémoire prévue. Selon Vercel, des chercheurs en ont tiré une fuite de mémoire et une exécution de commandes. Il faut pour cela que l'application décompresse des données venues de l'extérieur, ce qui arrive plus souvent qu'on ne le croit : la réponse compressée d'un service tiers interrogé par l'application suffit. Les règles de pare-feu applicatif ne couvrent pas ce cas ; seule la mise à jour le fait.
Les trois autres failles élevées concernent la vérification des certificats TLS et la résolution des noms de domaine. La même mise à jour retire aussi la confiance accordée aux certificats d'autorités intermédiaires compromises d'eMudhra, déjà bloquées par Firefox et Chrome depuis le 17 octobre.
À la date de cet article, aucune exploitation n'est signalée, aucune démonstration n'est publique, le CERT-FR n'a pas publié d'avis et les fiches officielles de ces failles ne sont pas encore en ligne. Ce dernier point a une conséquence pratique : les outils qui analysent les dépendances à partir de ces fiches ne les signalent peut-être pas encore. Il ne faut pas attendre leur alerte pour mettre à jour.
Node 20 et Node 25 ne sont plus corrigés
Node.js 20 est en fin de vie depuis le 30 avril 2026, Node.js 25 depuis le 1er juin. Ni l'un ni l'autre ne reçoit ces correctifs, et ils n'en recevront plus. Une application qui tourne encore sur Node 20 doit passer en 22 ou en 24. Node 24 vient d'entrer en phase de maintenance, et Node 26 devient la version de support long à partir du 28 octobre : c'est la cible pour un nouveau projet. Chez nous, le serveur du site ne fait pas tourner Node.js ; nous avons mis à jour Node.js sur les postes et les chaînes qui servent à construire nos sites, comme sur les serveurs de nos clients qui l'utilisent.
npm, la chaîne des dépendances visée
Le risque Node.js ne s'arrête pas au moteur. Une application moderne embarque des centaines de paquets npm, et ce sont eux que visent les attaques de ces derniers mois. En août, le ver ChainDrop, une variante de Shai-Hulud décrite par Microsoft, a compromis plus de 400 paquets pour voler les identifiants des développeurs. Le 8 octobre, le paquet tensorlake a été piraté et publié par la chaîne officielle du projet, avec une provenance en règle. Comme le résume Endor Labs, la provenance dit d'où vient un paquet, pas que sa source était saine.
Le 14 octobre, Next.js, un cadre de développement très répandu, corrigeait de son côté deux failles critiques d'exécution de code. Pour une PME, cela veut dire que le poste du développeur et la machine qui construit le site sont des cibles au même titre que le serveur.
Ce qu'il faut faire cette semaine
Faire l'inventaire de vos versions
Listez ce qui, chez vous, est exposé à Internet : site vitrine, boutique en ligne, extranet, logiciel métier en ligne, outils d'automatisation, interface d'administration d'un NAS ou d'un pare-feu. Pour chacun, trois questions : tourne-t-il sur PHP ou sur Node.js, dans quelle version, et qui le met à jour ? Une ligne sans réponse est une ligne à traiter en premier.
Mettre à jour, puis redémarrer
Pour PHP, visez au moins 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou le paquet corrigé de votre distribution. Pour Node.js, 22.23.4, 24.22.1 ou 26.12.1. Redémarrez ensuite les services, reconstruisez les images Docker et redéployez. Si vous utilisez Next.js, passez en 16.4.1 ou en 15.5.28.
Contrôlez après coup que la version en service est bien la nouvelle. Le jour d'une alerte, il est facile de mettre à jour un serveur et d'en oublier un autre.
Si la mise à jour doit attendre
PHP et le CERT-FR publient des mesures temporaires. La plus simple consiste à désactiver le suivi de progression des envois de fichiers (session.upload_progress.enabled) dans la configuration de PHP elle-même, pas dans le code du site, puis à redémarrer PHP. Elle ne protège que de l'une des deux failles. L'avis de PHP ajoute des réglages de mémoire et de taille des envois, et le CERT-FR propose de bloquer les envois de formulaires de type multipart au pare-feu applicatif, ce qui casse au passage les envois de fichiers. Un pare-feu applicatif comme celui de Cloudflare apporte une protection partielle.
Ces mesures réduisent le risque, elles ne rendent pas le serveur sûr : PHP le dit lui-même. Si aucune n'est possible, les autorités recommandent de couper le site jusqu'à la mise à jour, comme l'ont fait les préfectures. Quelques heures hors ligne coûtent moins cher qu'un serveur à reconstruire.
Les bibliothèques aussi
Un site PHP ou Node.js embarque des bibliothèques qui ont leurs propres failles. Leurs auteurs publient des correctifs tout au long de l'année, et nous avons mis à jour celles de nos sites dans la foulée de l'alerte. Les outils existent pour savoir où l'on en est : composer audit pour PHP, npm audit pour Node.js. C'est l'occasion d'appliquer à vos sites la même discipline que pour les mises à jour de sécurité de vos postes.
Votre site a pu être visé : que vérifier
Si votre serveur est resté vulnérable pendant la journée du 21 octobre, ou plus longtemps, la mise à jour ne suffit pas : il faut vérifier qu'il n'a pas été atteint avant.
Les signes cités par les chercheurs et les éditeurs de sécurité sont discrets, et la plupart échappent aux journaux du site lui-même. Des envois de formulaires inhabituels suivis d'erreurs de mémoire, des réponses en erreur 500 répétées, des cookies de session anormalement longs, des redémarrages inexpliqués de PHP. Plus grave : PHP qui lance des commandes système ou télécharge des outils, de nouveaux fichiers dans le dossier du site, des tâches planifiées ou des comptes créés que personne ne reconnaît. L'absence de ces signes ne prouve pas que le serveur est sain.
En cas de doute, isolez le serveur et conservez ses journaux avant toute chose. Changez ensuite les mots de passe et les clés qu'il contient (base de données, services de messagerie, clés d'accès à des services en ligne), puisque la mémoire du serveur a pu fuir. Si une compromission se confirme, on ne nettoie pas un serveur, on le reconstruit et on restaure le site depuis une sauvegarde externalisée antérieure à l'attaque. Notre guide sur le site WordPress piraté détaille la remise en état du site lui-même, et celui sur les virus et logiciels malveillants aide à reconnaître ce qu'on a en face de soi.
Rester prudent dans les jours qui viennent
Les jours qui suivent une publication comme celle-ci sont les plus risqués. Les robots balaient Internet à la recherche des serveurs restés en arrière, et l'outil d'attaque public sert précisément à cela. Wiz s'attend à d'autres variantes de ces failles, et les sites compromis serviront ensuite de relais pour de l'hameçonnage ou pour diffuser des logiciels malveillants.
Méfiez-vous des « correctifs » non officiels et des extraits de configuration copiés depuis un forum : Patchstack et Huntress mettent en garde contre eux. Les seules versions sûres sont celles du projet PHP, de Node.js et de votre distribution.
Un dernier réflexe, plus général : un courriel pressant qui vous demande d'installer une « mise à jour de sécurité PHP » ou de vous reconnecter d'urgence à l'espace client de votre hébergeur se vérifie par un autre canal avant tout clic. Aucune campagne de ce type n'est signalée à ce jour, mais les escrocs suivent l'actualité de près ; notre guide sur l'hameçonnage donne les signes à repérer.
Ce que cette journée nous a rappelé
Ce qui a fait gagner du temps le 21 octobre, ce n'est pas la vitesse d'exécution. C'est de savoir déjà, avant l'alerte, quels serveurs faisaient tourner quoi, dans quelle version, et comment revenir en arrière si une mise à jour cassait un site. Avec cette carte en main, une alerte critique devient une liste de gestes connus.
Pour les sites dont nous assurons la maintenance, tenir cette carte à jour et vérifier les versions font partie du travail courant ; pour les serveurs et les postes, c'est le socle de notre accompagnement en cybersécurité, avec une supervision informatique qui voit ce qui sort de l'ordinaire.
Si vous ne savez pas quelle version de PHP ou de Node.js fait tourner votre site, c'est la première chose à demander cette semaine, à votre hébergeur ou à votre prestataire. Et si vous n'avez personne à qui poser la question, écrivez-nous : nous regardons avec vous.
Liste de contrôle après les failles PHP et Node.js
- Lister les sites et outils exposés à Internet, et pour chacun : PHP ou Node.js, version, responsable de la mise à jour.
- Obtenir de l'hébergeur une confirmation écrite pour chaque site en hébergement mutualisé.
- Mettre à jour PHP (8.2.35, 8.3.36, 8.4.27, 8.5.12 ou paquet corrigé) et Node.js (22.23.4, 24.22.1, 26.12.1).
- Redémarrer les services, reconstruire et redéployer les images Docker.
- Contrôler la version réellement en service après la mise à jour.
- Passer les bibliothèques au crible (composer audit, npm audit) et corriger.
- Planifier la sortie de PHP 8.1, de Node.js 20 et de toute version en fin de vie, et celle de PHP 8.2 avant le 31 décembre 2026.
- Chercher les signes de compromission sur tout serveur resté vulnérable, et changer ses mots de passe et clés en cas de doute.
- Vérifier qu'une sauvegarde récente existe hors du serveur, et qu'elle se restaure.
- Se méfier des correctifs non officiels et des courriels qui exploitent l'actualité.
Quelle version fait tourner votre site ?
Un relevé des versions de PHP et de Node.js en service, et de qui les met à jour.
Puis ce qu'il faut corriger, et dans quel ordre.
Questions fréquentes sur les failles PHP2Shell et Node.js
Comment savoir si mon site est concerné par PHP2Shell ?
Votre site est concerné s'il fonctionne avec PHP, comme WordPress, PrestaShop, Joomla ou Drupal, et si la version de PHP du serveur est antérieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. La version apparaît dans l'espace client de votre hébergeur, ou dans l'outil Santé du site de WordPress. Sur Debian, Ubuntu ou Red Hat, c'est le numéro du paquet installé qui fait foi.
Un site WordPress à jour est-il protégé ?
Non. Les failles sont dans PHP, pas dans WordPress ni dans ses extensions. Un WordPress à jour posé sur un PHP non corrigé reste exposé : c'est le PHP du serveur qui doit être mis à jour.
Mon hébergeur s'occupe-t-il de la mise à jour ?
En hébergement mutualisé, c'est en principe l'hébergeur qui met PHP à jour : OVHcloud l'a par exemple annoncé le 21 octobre 2026 ; demandez-lui une confirmation écrite plutôt que de la supposer. Sur un serveur privé virtuel, un serveur dédié ou un conteneur, la mise à jour vous revient.
Que faire si je ne peux pas mettre à jour tout de suite ?
Appliquer les mesures temporaires publiées par PHP et le CERT-FR, comme la désactivation du suivi de progression des envois de fichiers, en sachant qu'elles réduisent le risque sans rendre le serveur sûr. Si aucune n'est possible, les autorités recommandent de mettre le site hors ligne jusqu'à la mise à jour, comme l'ont fait les préfectures le 21 octobre 2026.
Les failles de Node.js concernent-elles un site WordPress ?
Un site WordPress classique ne fait pas tourner Node.js sur son serveur : il est concerné par les failles de PHP, pas par celles de Node.js. Node.js concerne les applications et outils qui l'utilisent côté serveur, ainsi que les postes et machines qui construisent des sites avec npm.