PHP et Node.js : deux alertes de sécurité le même jour

PHP et Node.js publient des correctifs de sécurité le 21 octobre 2026 : deux vulnérabilités critiques pour PHP et dix vulnérabilités pour Node.js. Pour un parc qui utilise ces deux moteurs, la priorité consiste à identifier les versions réellement exécutées, appliquer les correctifs adaptés et conserver une preuve par environnement. Les deux alertes appellent une méthode commune de suivi, avec des vérifications propres à chaque technologie.

Que corrigent PHP et Node.js le 21 octobre 2026 ?

L’annonce officielle PHP vise les installations qui servent des requêtes web, notamment PHP-FPM, Apache avec mod_php, CGI, FrankenPHP et LiteSpeed. CVE-2026-109618 et CVE-2026-109619 peuvent permettre une exécution de code à distance sans authentification. Les deux avis PHP attribuent chacun un score CVSS 4.0 de 9,2/10, classé critique.

Le premier défaut concerne une corruption liée à la gestion d’une mémoire insuffisante ; le second, un état interne conservé après la libération de la mémoire d’une requête. PHP considère le risque le plus élevé avec mod_php. Les conditions varient selon les modes d’exécution : utiliser PHP-FPM ne suffit pas à écarter les deux avis.

L’annonce Node.js décrit quatre failles de gravité haute, trois moyennes et trois basses. Elle comprend CVE-2026-111497, une écriture hors limites dans le décodeur Brotli pouvant permettre une exécution de code à distance, ainsi que des défauts de vérification des noms d’hôte TLS et de traitement des noms DNS.

Les périmètres diffèrent : CVE-2026-105483 concerne les branches 24 et 26, tandis que la faille Brotli concerne les branches 22, 24 et 26. Notre analyse des failles Node.js d’octobre 2026 détaille ce lot. Au 21 octobre, l’annonce Node.js consultée ne précise pas si ces vulnérabilités ont été exploitées dans la nature ; elle ne permet pas de conclure à une absence d’attaques.

Inventaire, restauration, tests et contrôle se partagent ; les correctifs de chaque moteur restent distincts.

Quelles versions corrigées et quelles fins de vie retenir ?

Les seuils ci-dessous sont les premières versions amont corrigées dans chaque branche. Les échéances correspondent à la fin du support officiel de sécurité, selon les calendriers consultés le 21 octobre 2026.

Les dates PHP viennent des pages Supported Versions et Unsupported Branches. Pour Node.js, le calendrier officiel du projet distingue ces échéances de la date de la dernière publication. Une mise à jour de PHP 8.2 corrige cette alerte, mais laisse à préparer sa sortie du support fin 2026.

Au 21 octobre, Node.js 26 reste au stade Current ; les branches 22 et 24 sont LTS. Pour une migration de production, retenez une branche LTS compatible avec l’application. Le choix de destination doit tenir compte de ses dépendances et de sa durée de support restante.

Comment inventorier ses serveurs et ses conteneurs ?

Construisez une ligne de suivi par service et par environnement. Voici une méthode proposée pour préparer la correction sans confondre plusieurs installations présentes sur une même machine.

1. Identifier le service et son responsable. Recensez sites, API, traitements en arrière-plan et applications hébergées par un prestataire. Séparez production, préproduction et environnements susceptibles d’être remis en ligne. Notez l’hébergeur et la personne qui peut autoriser l’intervention.
2. Relever le moteur réellement utilisé. Sur un serveur administré avec autorisation, php -v et node -v renseignent le binaire appelé dans le terminal. Recoupez ce relevé avec le service : pool PHP-FPM, module Apache, chemin du binaire Node.js ou configuration du gestionnaire de processus. La version du terminal ne prouve pas celle du service web.
3. Identifier le paquet fournisseur. Conservez sa révision complète et l’avis qui documente les correctifs. Pour PHP, un fournisseur peut rétroporter les corrections sans reprendre le numéro amont. Demandez une confirmation couvrant les deux CVE et vérifiez que le service utilise ce paquet.
4. Documenter chaque conteneur. Relevez l’image, son étiquette, son empreinte et la version du moteur à l’intérieur du conteneur actif. Vérifiez aussi les différentes répliques. Distinguez une utilisation pendant la fabrication de l’image de la présence du moteur dans l’image finale.
5. Garder les inconnues visibles. Une version non relevée ou un correctif fournisseur non documenté reste à qualifier. Ajoutez la source de vérification, l’action attendue et le responsable de validation avant de classer l’environnement comme corrigé.

Lorsque ces services alimentent des applications IA, la gouvernance IA aide à attribuer les responsabilités sur leurs dépendances techniques. L’inventaire doit permettre de joindre l’équipe qui exploite le moteur, y compris lorsque celle qui développe l’application est différente.

Pourquoi faut-il reconstruire et redéployer les images ?

La version de l’hôte ne suffit pas à établir la correction d’un conteneur. Docker décrit les images comme des instantanés immuables et recommande leur reconstruction avec des dépendances actualisées. Son guide distingue le rafraîchissement de l’image de base et l’invalidation du cache de construction.

Pour chaque application concernée, sélectionnez une base corrigée ou le paquet fournisseur documenté, reconstruisez l’image, puis testez et déployez le nouvel artefact selon votre procédure. Vérifiez ensuite l’image et le moteur utilisés par chaque réplique. Un redémarrage de l’ancien conteneur conserve son ancien contenu.

Conservez l’empreinte de l’image validée et associez-la au relevé de production. Vérifiez également les modèles de déploiement et les images prévues pour un retour arrière : leur réutilisation pourrait remettre une version vulnérable en service. Cette étape complète le contrôle des processus déjà actifs.

Comment prioriser les interventions et vérifier la correction ?

Croisez l’exposition réelle, les fonctions utilisées et la preuve du correctif. Pour PHP, examinez le mode web et les conditions des deux avis. Pour Node.js, relevez notamment les communications HTTPS sortantes, la résolution DNS et le traitement de contenus compressés. Une application interne doit aussi être examinée lorsqu’elle traite des données provenant d’autres systèmes.

Préparez une sauvegarde restaurable, un environnement de test et une procédure de retour arrière. Pour PHP 8.1 ou Node.js 18 et 20, organisez une migration vers une branche maintenue ; tout support prolongé fournisseur doit être documenté séparément du support officiel du projet.

Après la mise à jour, contrôlez à nouveau le moteur actif. Testez les parcours applicatifs retenus, les sessions et formulaires concernés pour PHP, puis les connexions HTTPS, la résolution DNS et les contenus compressés utilisés par l’application Node.js. Ces contrôles fonctionnels doivent accompagner la preuve du correctif installé.

La clôture réunit le relevé avant intervention, l’avis applicable, la version ou le paquet corrigé, l’artefact déployé, les processus renouvelés et les résultats des tests. Datez la validation pour chaque environnement. Une page qui répond normalement ne démontre pas à elle seule l’installation des correctifs.

Comment Noolya intervient-elle ?

Noolya intervient pour vérifier l’exposition et organiser la mise à jour des environnements PHP et Node.js. Le périmètre peut comprendre l’inventaire, la coordination avec les hébergeurs, la préparation des correctifs, la reconstruction des images, la mise à jour autorisée, les tests et le contrôle après intervention.

Le diagnostic faille PHP et le diagnostic faille Node.js préparent un premier état déclaratif. Ces questionnaires ne réalisent aucun scan et ne prouvent pas l’installation d’un correctif. Pour définir les vérifications et les actions sur votre parc, contactez Noolya.

Questions fréquentes

Une application qui utilise PHP et Node.js demande-t-elle deux vérifications ? Oui, chaque moteur possède ses propres versions corrigées et conditions d’exposition. Il faut identifier les services qui utilisent chacun d’eux, puis conserver une preuve de correction pour chaque environnement concerné.

La mise à jour de l’hôte corrige-t-elle les conteneurs ? Elle ne prouve pas que leur contenu a changé. Il faut reconstruire et redéployer les images concernées, puis vérifier le moteur effectivement présent dans les conteneurs actifs.

PHP 8.2.35 permet-il de reporter la migration de branche ? Cette version corrige les deux vulnérabilités PHP de l’alerte. Le support officiel de sécurité de PHP 8.2 se termine néanmoins le 31 décembre 2026 : la migration reste à planifier.

Un diagnostic déclaratif peut-il certifier que le parc est corrigé ? Non, ses réponses aident à repérer les informations connues et les vérifications manquantes. La validation demande des preuves relevées sur les services et les conteneurs réellement exécutés, avec les résultats des tests.

Sources

• Security advisory: Critical remote code execution vulnerabilities, update now : PHP, annonce du 21 octobre 2026, versions et périmètre web.
• RCE via OOM corruption : avis PHP sur CVE-2026-109618, gravité et conditions.
• RCE via stale global state : avis PHP sur CVE-2026-109619, gravité et conditions.
• Supported Versions : calendrier PHP ; anciennes branches vérifiées aussi dans la page Unsupported Branches citée plus haut.
• Wednesday, October 21, 2026 Security Releases : annonce Node.js, gravités, branches et liens vers les versions corrigées.
• Node.js Releases : statut des branches au 21 octobre 2026.
• schedule.json : calendrier officiel Node.js, dates de fin de support.
• Building best practices : Docker, reconstruction des images, image de base et cache.

Couverture : logo PHP de Colin Viebrock, CC BY-SA 4.0, intégré à une composition diffusée sous la même licence. Référence officielle PHP. Marque officielle Node.js. Aucune approbation des projets n’est suggérée.