PHP et Node.js : les vulnérabilités d'octobre 2026

Le 21 octobre 2026, nous avons contrôlé des centaines de services répartis entre conteneurs, environnements Node.js et applications PHP, et mis à jour dans la journée tous ceux qui étaient exposés. Nous avons ensuite vérifié les processus réellement en cours d'exécution, fait passer des milliers de tests automatisés sur des copies isolées des environnements applicatifs et surveillé les endpoints en production jusqu'à n'obtenir que des réponses HTTP correctes. Le plus exigeant a été de garder fonctionnels les applications, les bases de données, la génération des factures et les personnalisations pendant que nous remplacions les runtimes.

Le travail a été déclenché par deux annonces distinctes, publiées le même jour : des vulnérabilités critiques dans PHP et des mises à jour de sécurité de gravité élevée pour Node.js. Elles concernent le logiciel qui exécute les applications. Pour une entreprise, cela signifie que le problème peut se trouver sous le site ou le logiciel de gestion, même lorsque le code écrit pour le projet n'a pas changé.

Voici la situation vérifiée au 21 octobre 2026. Les versions indiquées sont celles qui corrigent ces bulletins ; pour une mise à jour effectuée plus tard, il faut aussi contrôler les versions de sécurité publiées depuis.

Mise à jour du 26 octobre : tentatives d'attaque avant l'annonce

Amazon Threat Intelligence a détecté dans ses capteurs MadPot une tentative d'exploitation de PHP2Shell le 17 octobre, quatre jours avant la divulgation publique du 21 octobre. L'analyse, publiée le 21 octobre, signale en outre des tentatives provenant de plusieurs infrastructures avant la fin de l'embargo. AWS précise que l'analyse technique est en cours et n'établit pas si ces tentatives auraient réussi sur des systèmes réels.

Cela change la période à couvrir lors des contrôles : pour un service exposé, AWS recommande de remonter au moins jusqu'au 17 octobre, en vérifiant les journaux, les exécutions de processus inattendues et les modifications de fichiers. Installer le correctif et chercher les traces d'une compromission antérieure sont deux vérifications distinctes. Une mise à jour terminée le 21 octobre ne prouve pas à elle seule que le système était intact les jours précédents.

Les vulnérabilités PHP : CVE-2026-109618 et CVE-2026-109619

Le bulletin officiel de PHP décrit deux failles qui peuvent permettre l'exécution de code à distance sans authentification. Une RCE, concrètement, signifie qu'un attaquant peut parvenir à exécuter du code sur le système via une vulnérabilité accessible à distance. Le fait qu'un site ait une page de connexion n'élimine pas un problème qui peut survenir avant que l'application ne vérifie les identifiants.

La CVE-2026-109618 concerne la gestion de l'épuisement de la mémoire : certaines données internes de la requête peuvent rester initialisées seulement en partie, puis être traitées comme valides lors du nettoyage. Le cas démontré sur Apache avec mod_php peut se déclencher avant l'exécution du code applicatif. L'analyse officielle considère PHP-FPM comme également vulnérable, avec des chemins d'attaque différents et sans démonstration complète d'un exploit FPM pour cette faille précise.

La CVE-2026-109619 concerne quant à elle un état interne qu'un processus peut conserver après la libération de la mémoire de la requête précédente. Une requête suivante peut accéder à ces références désormais invalides. Les conditions dépendent du comportement du worker et des opérations accessibles : présenter chaque installation comme déjà compromise serait inexact, mais la considérer comme sûre sans le correctif le serait tout autant.

Pour qui gère un site, la conséquence pratique est claire : mettre à jour le CMS ou ses plugins peut être nécessaire, mais corriger ces failles exige aussi un runtime PHP à jour. Le problème peut toucher un logiciel de gestion sur mesure autant qu'un site WordPress.

Quelles versions de PHP et Node.js contiennent les correctifs

Voici les versions upstream indiquées par les projets pour les bulletins du 21 octobre :

Runtime	Branche	Version corrigée
PHP	8.2	8.2.35
PHP	8.3	8.3.36
PHP	8.4	8.4.27
PHP	8.5	8.5.12
Node.js	22	22.23.4
Node.js	24	24.22.1
Node.js	26	26.12.1

Le tableau résume les versions de PHP et le bulletin Node.js. Il ne suggère pas de passer à la version majeure la plus élevée sur chaque application : il faut d'abord vérifier la compatibilité, les dépendances et les extensions natives.

Un détail change aussi le diagnostic : le numéro de version upstream ne suffit pas pour juger un paquet Linux. Une distribution peut appliquer le correctif tout en conservant une version de base apparemment ancienne. Pour PHP 8.3 sur Ubuntu 24.04, par exemple, les fiches officielles de CVE-2026-109618 et CVE-2026-109619 indiquent le paquet corrigé 8.3.6-0ubuntu0.24.04.13. Il faut lire la révision complète et le bulletin du fournisseur. Le même principe impose la prudence avec les branches qui ne sont plus supportées : il faut un correctif documenté par votre fournisseur, ou une migration vers une branche maintenue.

La même limite vaut pour les contrôles effectués de l'extérieur. Notre Recensement de la sécurité du secteur public suisse vérifie chaque jour environ 2200 communes, cantons et offices fédéraux en n'utilisant que des données publiques, et compare de manière passive la version de PHP qu'un site déclare dans ses en-têtes avec la version corrigée. C'est un indice utile pour avoir une vue d'ensemble, pas un diagnostic : beaucoup de serveurs n'affichent pas leur version, et un paquet auquel la distribution a appliqué le correctif peut sembler ancien. Pour savoir ce qui tourne vraiment, il faut regarder à l'intérieur du serveur.

Node.js, Brotli et le risque derrière la compression

Le bulletin Node.js d'octobre inclut la CVE-2026-111497, un défaut du décodeur Brotli classé de gravité élevée qui peut permettre l'exécution de code à distance. Brotli est un format de compression utilisé notamment dans le trafic web. L'exposition réelle dépend des chemins par lesquels l'application traite des données compressées qu'un attaquant peut contrôler ; le simple fait d'avoir Node.js installé ne prouve pas qu'un exploit soit atteignable.

La même version contient des correctifs touchant le DNS, la vérification des certificats TLS et d'autres composants. C'est pourquoi nous avons mis à jour les runtimes concernés et vérifié aussi la compression, l'initialisation TLS et la cryptographie. Un test qui compresse et décompresse correctement des données contrôle la compatibilité du nouvel environnement ; la preuve que le correctif est inclus vient en revanche de la version corrigée et de la provenance vérifiée du logiciel.

Pour les applications encore sous Node.js 20, nous avons préparé une migration vers une branche maintenue. Les extensions natives méritent un test à part : un module SQLite compilé pour un runtime antérieur peut devoir être recompilé lors d'un changement de version majeure.

Pourquoi mettre à jour le serveur ne met pas automatiquement à jour Docker et PM2

Sur une infrastructure réelle peuvent cohabiter le PHP du système, celui d'un conteneur Apache et celui d'une application PHP-FPM. En corriger un laisse les autres en place. Même la version renvoyée par une commande dans le terminal doit être comparée à celle du processus qui sert réellement les requêtes.

Avec Docker, nous avons contrôlé les images réellement actives, préparé leurs remplaçantes et conservé les volumes de données. Un tag nommé latest ne garantit pas qu'un correctif est inclus, et une reconstruction future peut annuler le travail si le Dockerfile ou la procédure de déploiement continuent de sélectionner une base ancienne. Au cours de cette intervention, nous avons aussi vérifié les paquets du fournisseur et, si nécessaire, préparé des runtimes à partir des sources officielles avec des sommes de contrôle vérifiées.

Avec PM2, changer le Node par défaut du shell ne remplace pas un exécutable déjà chargé en mémoire. Nous avons vérifié le démon, les processus enfants et la supervision systemd. Le travail a aussi nécessité des restaurations et des corrections de la procédure : la possibilité de revenir à une configuration fonctionnelle faisait partie de la préparation.

Mettre à jour PHP et Node.js sans perdre personnalisations et données

Avant le changement, nous avons conservé les images précédentes et préparé des copies des bases de données et des volumes utiles aux tests. Sur le système de monitoring, nous avons comparé des milliers de fichiers PHP et MIB avec le snapshot d'origine, en utilisant les mêmes montages en lecture seule. Sur le service de facturation, nous avons testé dans le clone la connexion, la lecture des clients et des factures, le téléchargement d'un PDF existant et la génération d'un document de test. En production, nous avons ensuite recontrôlé l'état du service et les réponses HTTP.

Les suites de tests des logiciels de gestion ont exécuté des milliers de tests sans aucun échec. Le redémarrage contrôlé final de ces services et la bascule définitive du service de facturation se sont faits sans interruption : la surveillance des endpoints en production a continué de recevoir des réponses correctes. Sur l'ensemble du travail, il y a aussi eu des tentatives et des rollbacks, préparés justement pour ne pas affecter les utilisateurs finaux.

Un healthcheck au vert indique qu'un contrôle précis fonctionne. Pour savoir si une application reste utilisable, il faut aussi tester les fonctions qui comptent : connexions, bases de données, documents, files de traitement et intégrations. C'est une part concrète de la gestion de l'hébergement en Suisse, à organiser avant que n'arrive le prochain bulletin urgent.

Les questions à poser à qui gère votre site

Un site protégé par un VPN doit-il être mis à jour ?

Oui. Le VPN limite qui peut atteindre un service par les accès qu'il protège ; le correctif élimine le défaut dans le runtime. Ce sont des mesures aux fonctions différentes. La présence d'un VPN aide à évaluer l'exposition et l'ordre des interventions, mais ne remplace pas un correctif.

Suffit-il de mettre à jour WordPress, Laravel ou le framework JavaScript ?

Pour ces vulnérabilités, il faut aussi vérifier PHP ou Node.js. Demandez à votre fournisseur quelle version exécute les requêtes, quelle révision du paquet inclut le correctif et quels contrôles ont été effectués après le redémarrage. Une application peut continuer à utiliser le runtime de sa propre image Docker même après la mise à jour du système d'exploitation.

Peut-on garantir une sécurité à 100 % après la mise à jour ?

Nous pouvons documenter les correctifs installés, les tests réussis et les contrôles effectués. Cela ne certifie pas l'absence de toute autre vulnérabilité ou d'une compromission antérieure. Lors de nos vérifications, nous avons par exemple consigné à part un avertissement non bloquant d'une dépendance applicative, déjà présent avant le changement de PHP. Distinguer correctifs de sécurité, compatibilité et anomalies préexistantes aide à prendre des décisions sensées.

Nous pouvons faire ce contrôle pour votre entreprise aussi

Chez Webcracy, nous pouvons vérifier quelles versions de PHP et de Node.js font tourner votre site ou votre logiciel de gestion, contrôler si les correctifs sont présents et identifier les services à mettre à jour en priorité. Nous vous remettons un état des lieux de ce que nous avons vérifié, des interventions nécessaires et des questions encore ouvertes.

Nous pouvons aussi nous charger des mises à jour : préparer les sauvegardes, tester les modifications sur des copies des données et contrôler les fonctions que vous utilisez chaque jour. Avant, nous convenons ensemble du calendrier et des modalités de l'intervention ; après, nous documentons les modifications et les tests effectués.

Dites-nous ce que vous utilisez et qui gère aujourd'hui votre hébergement : nous partirons de là, y compris en impliquant votre fournisseur actuel.

Parlons de votre site ou de votre logiciel de gestion↗

Photo d'illustration : Taylor Vick sur Unsplash, utilisée selon la licence Unsplash. Le data center représenté n'est pas celui de l'intervention.