Tous les articles
Technique6 min de lecture

Failles PHP et Node.js du 21 octobre 2026 : ce qui s'est passé sur vos sites

PHP2Shell et faille Brotli de Node.js expliquées sans jargon : ce qui était en jeu, ce que nous avons corrigé le jour même, et les questions à poser à votre prestataire.

Mercredi 21 octobre, PHP et Node.js ont publié le même jour des correctifs pour des failles graves. Si votre site a été fait ou est maintenu par Start-Win, il a été mis à jour dans la journée et aucune fuite de données n'est à déplorer. Vous n'avez rien à faire, pas de mot de passe à changer.

Le reste de cet article explique ce qui s'est passé, en français normal. Parce que la prochaine fois, ce sera peut-être le site d'un de vos proches qui ne sera pas suivi.

PHP et Node.js, c'est le moteur sous le capot

Quand quelqu'un ouvre votre site, un programme tourne sur le serveur et fabrique la page à la volée. Ce programme, c'est souvent PHP (tous les sites WordPress, une bonne partie du web) ou Node.js (la plupart de nos sites faits à la main, dont start-win.fr). Vous ne le voyez jamais. Il est là quand même, comme le moteur d'une voiture dont vous ne regardez que la carrosserie.

Une faille, c'est un défaut dans ce moteur. Celles-ci étaient du pire genre : ce que les spécialistes appellent une « exécution de code à distance ». Traduction : quelqu'un, depuis n'importe où dans le monde, sans identifiant, peut envoyer une requête piégée au serveur et lui faire exécuter ses propres instructions. Lire des fichiers, installer quelque chose, récupérer des données.

Côté PHP : « PHP2Shell »

Deux failles, CVE-2026-109618 et CVE-2026-109619, vite surnommées « PHP2Shell ». Elles sont notées 9,2 sur 10 sur l'échelle de gravité utilisée par toute la profession. Pour faire simple, PHP oubliait de faire le ménage dans sa mémoire après certaines erreurs, et une requête bien fabriquée pouvait profiter de ce désordre.

Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. WordPress.org a confirmé qu'aucune mise à jour de WordPress lui-même n'était nécessaire : le correctif se fait sur le serveur, pas dans le tableau de bord. C'est justement le piège. Un client qui met consciencieusement à jour ses extensions WordPress chaque mois n'était pas protégé pour autant.

Côté Node.js : un fichier compressé qui déborde

Le même jour, Node.js corrigeait dix failles d'un coup, dont quatre jugées graves. La plus sérieuse, CVE-2026-111497, se trouvait dans le module qui décompresse les données au format Brotli (un format de compression très courant sur le web). Un fichier compressé mal formé, envoyé exprès, faisait écrire le serveur en dehors de la zone de mémoire prévue. Au mieux, le site plantait. Au pire, l'attaquant prenait la main.

Versions corrigées : Node.js 26.12.1, 24.22.1 et 22.23.4.

Ce que nous avons fait, et quand

Les correctifs ont été appliqués sur nos serveurs dès leur publication, le 21 octobre. PHP d'abord, pour les sites WordPress que nous hébergeons et maintenons, puis Node.js pour les sites que nous développons nous-mêmes.

Dans les trois jours qui ont suivi, nous avons aussi repassé en revue les briques logicielles que nos sites utilisent par-dessus Node.js : le framework, la bibliothèque qui vérifie les formulaires, celle qui envoie les e-mails de contact. Plusieurs avaient elles aussi un correctif de sécurité en attente. Tout a été mis à jour et redéployé le 24 octobre.

Aucune donnée n'a fuité.

Pourquoi « le jour même » n'est pas un détail

Dès le 21 octobre, la société de sécurité watchTowr signalait des attaques réelles contre PHP. Rapid7, un autre acteur reconnu, constatait des tentatives d'exploitation et des programmes d'attaque déjà publics.

Ce délai très court s'explique simplement. Les pirates ne choisissent pas votre site. Ils lancent des robots qui testent des millions d'adresses à la suite, sans regarder si c'est une multinationale ou un cabinet de sophrologie à Vallet. Une TPE n'est pas trop petite pour être touchée. Elle est simplement sur la liste, comme tout le monde.

Un site laissé une semaine sans correctif après une annonce pareille, c'est une porte restée ouverte pendant que des inconnus essaient toutes les poignées de la rue.

Les versions trop anciennes ne sont plus réparées

C'est le point que je voudrais que vous reteniez. PHP 8.1 et les versions plus anciennes n'ont reçu aucun correctif officiel. Même chose pour Node.js 20 et avant. Ces versions sont en « fin de vie » : plus personne n'est payé pour les réparer.

Or on croise encore régulièrement, lors de nos audits, des sites montés il y a cinq ou six ans qui tournent sur PHP 7.4. Ils s'affichent bien. Rien ne clignote. Le propriétaire pense que tout va bien parce que rien ne se voit, et c'est exactement ce qui rend la situation dangereuse.

Une mise à jour de version ne se fait pas en un clic, d'ailleurs. Il faut vérifier que le thème et les extensions suivent, tester, parfois corriger. C'est du travail de maintenance, et c'est pour ça qu'il doit être fait en continu, pas le jour où une alerte tombe.

Votre site n'est pas chez nous ? Quatre questions à poser

  1. Quelle version de PHP (ou de Node.js) fait tourner mon site aujourd'hui ?
  2. Qui applique les correctifs de sécurité du serveur, et sous quel délai ?
  3. Les failles du 21 octobre ont-elles été corrigées sur mon site, et quel jour ?
  4. Si mon site est piraté demain, existe-t-il une sauvegarde récente, et qui la restaure ?

Une réponse floue, ou « je regarde et je reviens vers vous », vous dit déjà beaucoup. Si vous préférez vérifier vous-même, notre audit de sécurité gratuit relève les signaux visibles de l'extérieur, et la page maintenance de site web détaille ce que comprend notre suivi. Le cadenas HTTPS, lui, est un autre sujet, traité dans site « non sécurisé » sur Google.

Et ce n'est pas tout à fait fini

Le 23 octobre, deux jours après, la fondation PHP a publié une nouvelle faille, CVE-2026-115560. Elle ne concerne que des configurations de serveur inhabituelles, et une parade existe, mais aucun correctif définitif n'est encore sorti. Nous la surveillons, et le correctif sera appliqué dès sa publication, comme les précédents.

À lire ensuite

← Retour au blog (26 articles)