PHP et Node.js : alerte piratage, les versions à corriger maintenant

Votre WordPress peut être à jour et son serveur rester vulnérable. C’est le piège de l’alerte qui touche PHP ce 22 octobre 2026 : deux failles critiques, regroupées sous le nom PHP2Shell, peuvent permettre une exécution de code à distance sans connexion préalable. Les correctifs sont disponibles depuis le 21 octobre. Node.js a également publié des mises à jour de sécurité le même jour, pour des problèmes distincts. Voici ce qu’il faut vérifier avant de se croire protégé. (1)(2)(3)

PHP2Shell : ce que permet réellement cette attaque

Les deux références à retenir sont CVE-2026-109618 et CVE-2026-109619. Elles touchent le moteur PHP qui exécute les sites, à un niveau inférieur au thème ou aux extensions. Une exploitation peut permettre de faire exécuter du code par le serveur : le problème dépasse donc le simple plantage d’une page. Le CERT-FR a publié son avis le 21 octobre. (2)

La seconde faille concerne notamment des données internes qui restent référencées après la libération de leur mémoire. Une requête ultérieure, traitée par le même processus, peut accéder à cet état devenu invalide. C’est un défaut de gestion de la mémoire, pas un mot de passe administrateur trop faible. L’exposition exacte dépend des opérations et de la configuration du serveur. (7)

L’équipe PHP considère le risque maximal avec Apache et mod_php : une attaque démontrée peut se déclencher avant l’exécution du code de l’application. PHP-FPM, php-cgi, FrankenPHP et LiteSpeed figurent aussi dans les installations à mettre à jour. Utiliser un autre mode que mod_php ne constitue donc pas une garantie de sécurité. (1)

Quelles versions de PHP corrigent les failles ?

Pour les branches maintenues, les correctifs publiés le 21 octobre sont les suivants. Une version antérieure dans la même branche doit être examinée sans attendre. (2)

• PHP 8.2 : 8.2.35
• PHP 8.3 : 8.3.36
• PHP 8.4 : 8.4.27
• PHP 8.5 : 8.5.12

PHP 8.1 et les branches plus anciennes ne reçoivent plus de mises à jour ordinaires du projet PHP. Certains fournisseurs proposent toutefois des correctifs rétroportés ; l’équipe a aussi fourni exceptionnellement des modifications minimales pour 7.4, 8.0 et 8.1. Demandez une confirmation précise à votre hébergeur : un ancien numéro accompagné d’un correctif fournisseur ne s’interprète pas comme une installation standard non corrigée. (1)

Node.js : une autre alerte, avec ses propres versions corrigées

PHP2Shell n’est pas une faille commune à PHP et Node.js. Le bulletin Node.js du 21 octobre répertorie dix vulnérabilités, dont les plus sévères sont classées « high ». L’une concerne le décodeur Brotli et peut permettre une exécution de code à distance : CVE-2026-111497. D’autres touchent notamment la validation des certificats TLS et le modèle de permissions. (3)

Les versions correctives annoncées sont Node.js 22.23.4, 24.22.1 et 26.12.1, selon la branche utilisée. Le fait qu’un service emploie Node.js ne suffit pas à prouver qu’il est exploitable par chaque faille : les fonctions sollicitées comptent également. (3)

Le lot met aussi à jour des dépendances, dont les certificats liés à l’incident eMudhra. Nous avons détaillé ce dossier dans notre article sur le correctif Firefox contre les certificats HTTPS compromis. Cette composante ne résume pas, à elle seule, l’alerte Node.js. (3)

Vous gérez un WordPress : où regarder et quoi demander ?

Dans l’administration, ouvrez Outils → Santé du site → Informations → Serveur. Relevez la version de PHP. Cet écran donne des informations techniques ; il ne réalise pas la mise à jour du serveur. Ne confondez pas ce numéro avec la version de WordPress affichée dans le tableau de bord. (6)

Sur un hébergement géré, le plus utile est d’envoyer au support une demande vérifiable, plutôt qu’un vague « mon site est-il sécurisé ? ». Vous pouvez reprendre cette formulation :

Mon hébergement exécute-t-il une version de PHP corrigée contre CVE-2026-109618 et CVE-2026-109619 ? Merci de préciser la version ou le correctif fournisseur appliqué, et de confirmer que les processus servant mon site utilisent bien cette version.

Une réponse limitée à « les extensions sont à jour » ne répond pas à la question. La vérification porte ici sur PHP. Si votre prestataire gère aussi une application Node.js, faites confirmer séparément sa branche et sa version. L’ENISA recommande justement de recenser les applications concernées et de coordonner la correction avec les hébergeurs, en priorisant les services exposés à Internet. (5)

Serveur ou application maison : vérifier le processus qui tourne vraiment

Pour un administrateur, php -v et node --version sont des points de départ pratiques. Mais ils indiquent les exécutables appelés dans ce terminal. Ils ne prouvent pas qu’un autre service, un conteneur ou un processus déjà démarré utilise la même installation.

Notre conseil : associez chaque site à son environnement réel, appliquez le correctif adapté, puis faites redémarrer ou redéployer les services concernés selon votre procédure habituelle. Contrôlez ensuite la version effectivement utilisée et les fonctions essentielles : connexion, formulaire, téléversement ou paiement selon le site. Une mise à jour des seules dépendances npm ne remplace pas automatiquement le moteur Node.js.

Pour éviter une mauvaise surprise, gardez une sauvegarde et vérifiez la compatibilité avant un changement de branche majeur. Il ne faut pas confondre l’installation rapide du correctif de sa branche et une migration improvisée de toute l’application.

Cloudflare suffit-il ? Et mon site est-il déjà piraté ?

Un pare-feu ne remplace pas le correctif PHP. Cloudflare indique avoir déployé des protections et observé du trafic d’attaque, avec des tentatives de modification des requêtes pour contourner ses règles. L’entreprise recommande néanmoins de mettre PHP à jour. Cela établit l’existence de tentatives réelles, pas la compromission de tous les sites concernés. (4)

PHP précise également que les mesures temporaires de configuration ne constituent pas une protection complète. Si la correction immédiate est impossible, l’ENISA recommande d’envisager l’isolement temporaire des applications exposées, avec le responsable de leur exploitation. (1)(5)

Un site qui s’affiche normalement peut encore être vulnérable ; inversement, une erreur ou une lenteur ne prouve pas une intrusion. En cas de soupçon concret, demandez à votre hébergeur une analyse des journaux et des fichiers, en conservant les éléments utiles. Corriger la faille et rechercher une éventuelle compromission sont deux vérifications différentes. Le bon réflexe aujourd’hui est d’obtenir une version corrigée confirmée, pas de se fier uniquement à l’apparence du site.