Deux failles critiques dans les logiciels de vos sites : un délai d'un mois n'est plus tenable

Votre site web, votre boutique en ligne ou votre outil de gestion interne repose sur des logiciels que personne, dans l'entreprise, ne sait nommer. L'un d'eux a reçu deux correctifs de sécurité critiques le 21 octobre 2026. Une semaine plus tard, l'agence américaine de cybersécurité confirmait que des attaquants les exploitaient déjà. La question n'est plus de savoir si votre prestataire va mettre à jour. Elle est de savoir quand, et qui le vérifie.

Ce qui s'est passé le 21 octobre

Deux logiciels très répandus ont publié un correctif le même jour.

Le premier est PHP, le langage de programmation qui fait tourner la majorité des sites web. Wiz, une société de sécurité rachetée par Google, estime que PHP équipe environ 70 % des sites dans le monde. WordPress, Drupal, Joomla et MediaWiki, le logiciel de Wikipédia, en dépendent directement.

Le second est Node.js, un environnement qui exécute du JavaScript sur un serveur. JavaScript est le langage des pages web ; Node.js permet de l'utiliser côté serveur, pour des applications, des interfaces et des services qui échangent des données.

Côté PHP, deux failles permettent à un attaquant non authentifié de faire exécuter ses propres instructions par le serveur. Les deux sont notées 9,2 sur 10, ce qui les place dans la catégorie critique. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Wiz indique que presque toutes les versions publiées depuis PHP 5.4, en 2012, sont concernées par au moins l'une des deux.

Côté Node.js, la faille touche le décodeur Brotli livré avec le logiciel. Brotli est un procédé de compression, c'est-à-dire un format qui réduit la taille des données échangées sur le web. Le décodeur qui reconstruit ces données pouvait écrire au-delà de la zone mémoire prévue. Node.js a corrigé le défaut dans les versions 22.23.4, 24.22.1 et 26.12.1, et précise qu'aucun contournement n'existe.

Pourquoi ces failles ne se corrigent pas comme les autres

Une faille qui permet d'exécuter du code à distance signifie qu'un attaquant fait tourner ses propres instructions sur votre machine, sans mot de passe. C'est la catégorie la plus grave.

Ces deux-là ont une particularité : elles se situent sous le code de votre application. Pour PHP, l'attaque peut aboutir avant que la première ligne de votre site ne s'exécute. Pour Node.js, le défaut est dans le composant de décompression intégré au serveur, pas dans une bibliothèque que votre équipe aurait ajoutée.

L'analogie est celle d'un immeuble. Vous pouvez changer les serrures de votre appartement. Si le défaut est dans la dalle du parking, la serrure ne sert à rien. Ici, la dalle, c'est le moteur qui traite les requêtes, en amont de votre code.

Conséquence directe : les journaux de votre application peuvent ne rien montrer. Wiz précise que l'attaque s'exécute sous la couche applicative, avec peu de contexte dans les journaux. Un pare-feu applicatif, qui filtre les requêtes selon des règles, peut bloquer certaines tentatives. Il ne corrige pas le défaut.

L'IA a changé le coût de l'attaque

Les failles de PHP ne sont pas neuves. Le code vulnérable existe depuis plus de dix ans, selon Wiz. Ce qui change, c'est le temps nécessaire pour transformer un défaut théorique en attaque qui fonctionne.

Wiz raconte avoir utilisé trois modèles d'IA, dont Gemini 4 Argon de Google et GPT-5.6 Sol d'OpenAI, pour trouver la faille, l'exploiter et vérifier le correctif. L'entreprise affirme qu'un seul chercheur a réalisé en une semaine un travail qui aurait demandé des mois à une équipe expérimentée. Elle précise que l'IA a surtout servi à adapter l'attaque à chaque version et à chaque configuration.

Cette affirmation vient d'une entreprise qui vend des outils de sécurité. Elle est pourtant cohérente avec un second cas. La faille Node.js a été signalée par l'équipe Codex Security d'OpenAI, selon l'avis officiel du projet Node.js.

Deux découvertes majeures la même semaine, avec l'IA comme accélérateur. La même technologie sert aussi à défendre : Wiz l'a employée pour vérifier le correctif avant publication. Le déséquilibre reste réel, car un correctif demande du temps de coordination, alors qu'une attaque demande une seule réussite.

Le calendrier ne laisse plus de marge

Pour PHP, les détails techniques ont fuité avant la publication du correctif. Des tentatives d'exploitation ont été observées le matin du 21 octobre. C'était plusieurs heures avant la mise à disposition des versions corrigées, selon la chronologie publiée par Sansec, une société spécialisée dans la sécurité des sites marchands.

L'agence américaine de cybersécurité a inscrit les deux failles PHP à son catalogue des vulnérabilités déjà exploitées le 26 octobre. Elle a fixé une échéance de trois jours aux agences fédérales, au 29 octobre. Pour Node.js, l'inscription date du 27 octobre, avec une échéance au 10 novembre.

Ces dates ne s'appliquent pas à votre entreprise. Elles donnent une mesure : trois jours pour une faille critique, dix jours pour l'autre. Un cycle de mise à jour mensuel ne tient pas ce rythme.

Un démonstrateur public est apparu le jour même, et l'exécution de code a été démontrée le 22 octobre sur l'image officielle de Node.js, selon Sysdig. La barrière technique baisse vite.

Les angles morts de votre inventaire

Le premier réflexe est de mettre à jour le système d'exploitation du serveur. Il ne suffit pas toujours. Node.js embarque sa propre copie du décodeur Brotli : mettre à jour la bibliothèque Brotli du système ne corrige pas le serveur Node.js, comme le rappelle CloudLinux pour ses paquets.

Les images de conteneurs forment le deuxième angle mort. Une image est un paquet figé, préparé à l'avance, qui contient le serveur et ses dépendances. Une image restée sur une ancienne version reste vulnérable tant qu'elle n'est pas reconstruite, même si vous changez le nom de la version dans vos fichiers de déploiement.

Troisième angle : les versions en fin de support. Node.js 20 et les versions antérieures ne recevront pas de correctif. PHP 8.1 et les versions antérieures non plus ; le projet a publié des correctifs minimaux pour ceux qui compilent eux-mêmes. PHP 8.2 sera à son tour abandonné le 31 décembre 2026.

Quatrième angle : les copies invisibles. Un serveur d'intégration, une machine de compilation ou une application autonome peuvent embarquer Node.js sans que personne ne le sache. L'agence américaine recommande d'inventorier, car ces logiciels sont souvent des composants d'autres produits.

Cinquième angle : l'hébergement mutualisé. Si votre site est hébergé chez un prestataire, la version de PHP dépend de lui. Demandez le numéro exact, pas la mention « à jour ».

Ce que je ferais cette semaine

Obtenez la version exacte, par écrit. Pour chaque site, chaque service en ligne et chaque outil interne, demandez le numéro de version de PHP et de Node.js. Une réponse vague est un risque en soi.

Corrigez d'abord ce qui est exposé à internet. Appliquez PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, et Node.js 22.23.4, 24.22.1 ou 26.12.1. Redémarrez ensuite les processus qui servent les pages, sinon l'ancien code reste en mémoire.

Reconstruisez les images de conteneurs. Changer un numéro de version dans un fichier ne remplace pas une image déjà construite. La nouvelle image doit être reconstruite puis redéployée.

Traitez la fin de support comme une échéance, pas comme un détail. Si une version ne reçoit plus de correctif, planifiez son remplacement avec une date. L'agence américaine va plus loin : pour les systèmes impossibles à corriger, elle recommande de les mettre hors ligne.

Vérifiez après coup. Contrôlez la version réellement active, la date de construction de l'image, et cherchez dans les journaux des processus de serveur web qui lancent des commandes ou téléchargent des outils. L'agence cite ce signal comme révélateur.

Mettez la question dans vos contrats. Demandez à votre hébergeur un engagement de délai de correction et une notification en cas de faille critique. Sans clause, vous découvrez le problème par la presse.

Ce qu'il faut retenir

• Deux failles critiques ont été corrigées le 21 octobre dans PHP et Node.js ; elles permettent à un attaquant de prendre le contrôle d'un serveur sans mot de passe.
• Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, et Node.js 22.23.4, 24.22.1 ou 26.12.1.
• Les deux failles sont déjà exploitées et inscrites au catalogue américain des vulnérabilités exploitées ; l'échéance fédérale pour Node.js est le 10 novembre.
• Les copies oubliées comptent : images de conteneurs figées, versions en fin de support et hébergement mutualisé peuvent rester vulnérables après la mise à jour du serveur principal.
• Un pare-feu applicatif réduit l'exposition, mais ne remplace pas le correctif. Faites confirmer la version exacte par écrit.