← Retour au journal
Publié le

Failles de sécurité d'octobre 2026 : PHP, Node.js, npm et Shopify, ce qu'il faut vérifier

En trois semaines, PHP et Node.js ont publié des correctifs critiques exploités en conditions réelles, et des boutiques Shopify ont vu leur tunnel de commande détourné par des applications tierces. Le point concret sur chaque faille et les actions à mener.

Trois écosystèmes qui font tourner une large part du web ont été touchés en même temps : PHP, qui motorise WordPress et la plupart des sites vitrines, Node.js, qui sert les applications modernes, et Shopify, côté e-commerce. Dans chaque cas, l’exploitation a commencé avant ou juste après la publication des correctifs. Voici ce qui s’est passé, et ce que vous devez vérifier sur votre site, que vous l’ayez développé vous-même ou qu’il soit hébergé chez un prestataire.

Vous voulez savoir où en est votre site avant de lire la suite ? Vérifiez-le en une minute avec l’outil gratuit : note de A à F, protections manquantes et action à mener pour chacune.

PHP : php2shell, deux failles critiques exploitées avant même leur annonce

Le 21 octobre 2026, l’équipe PHP a publié une mise à jour d’urgence pour deux failles référencées CVE-2026-109618 et CVE-2026-109619, surnommées « php2shell ». Toutes deux sont notées 9,2 sur 10. Elles permettent à un attaquant d’exécuter du code sur le serveur sans aucun compte, par une simple requête HTTP.

  • La première corrompt la mémoire pendant la gestion d’un dépassement de mémoire.
  • La seconde exploite un état conservé entre deux requêtes (use-after-free).

Les détails ont fuité sur les réseaux sociaux le 20 octobre, un jour avant la date prévue. Amazon avait déjà observé une tentative d’exploitation le 17 octobre. Le 26 octobre, l’agence américaine CISA a inscrit les deux failles à sa liste des vulnérabilités exploitées.

Versions corrigées : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les branches 8.1 et antérieures ne reçoivent pas de version officielle, seulement des correctifs de code source à appliquer soi-même ou via votre distribution Linux.

Qui est concerné : toute installation qui sert des requêtes web, en PHP-FPM, mod_php, php-cgi, FrankenPHP ou LiteSpeed. Le risque est le plus élevé avec mod_php, où la faille se déclenche avant même que votre application ne s’exécute. Un site WordPress, PrestaShop ou Laravel est concerné par définition.

Pour vérifier votre version et redémarrer les processus après mise à jour :

# Affiche la version de PHP en ligne de commande
php -v

# Sur un serveur Debian ou Ubuntu avec PHP-FPM : redémarrage obligatoire,
# la mise à jour du paquet ne touche pas les processus déjà en mémoire
sudo systemctl restart php8.3-fpm
sudo systemctl reload nginx

Point d’attention : les versions 8.4.27 et 8.5.12 contiennent une régression qui peut faire planter les applications utilisant l’extension SimpleXML. Le correctif est fusionné dans le code source mais n’était pas encore publié au 26 octobre. Testez avant de déployer en production.

Si la mise à jour est impossible dans l’immédiat, PHP recommande deux réglages temporaires, à placer dans un fichier que l’application ne peut pas surcharger :

; Neutralise CVE-2026-109618 (gestion du dépassement de mémoire)
memory_limit = -1

; Neutralise CVE-2026-109619 (état conservé entre requêtes)
session.upload_progress.enabled = 0

Puis redémarrez tous les processus PHP. Ces réglages ne remplacent pas la mise à jour, ils gagnent du temps.

Si votre site est chez un hébergeur mutualisé, vous n’avez rien à installer vous-même. Mais vérifiez dans votre panneau d’administration la version de PHP sélectionnée : beaucoup d’hébergeurs laissent le choix, et un site resté en 7.4 ou 8.0 n’a aucune version corrigée disponible.

Node.js : Node2Shell, une faille dans la décompression Brotli

Le même 21 octobre, Node.js a publié des correctifs pour dix failles, dont CVE-2026-111497, surnommée « Node2Shell ». C’est une écriture hors limites dans le décodeur Brotli embarqué dans le module node:zlib. Un flux Brotli malformé suffit pour faire planter le processus, lire sa mémoire ou exécuter du code.

Versions corrigées : 22.23.4, 24.22.1 et 26.12.1. Les lignes 20, 23 et 25 sont abandonnées et ne recevront aucun correctif.

Ce qui rend cette faille concrète, ce sont les chemins d’attaque ordinaires :

  • Express 5 et body-parser 2 décompressent par défaut les corps de requête envoyés avec l’en-tête Content-Encoding: br. N’importe quel visiteur peut donc envoyer le flux malveillant à votre API.
  • La fonction fetch() intégrée décompresse automatiquement les réponses Brotli. Un serveur tiers compromis peut viser votre application quand elle l’interroge.
  • Tout code qui passe des données non maîtrisées à zlib.brotliDecompress().

Un serveur HTTP Node.js nu, sans middleware de parsing, ne décode pas les corps entrants et n’est pas exposé par ce chemin.

# Version en cours d'exécution
node -v

# Dans un Dockerfile, fixez une version corrigée plutôt qu'un tag flottant
# FROM node:22-alpine devient :
# FROM node:22.23.4-alpine

Si vous ne pouvez pas mettre à jour immédiatement et que votre application n’a pas besoin de recevoir des requêtes compressées, désactivez la décompression côté body-parser :

// Les requêtes compressées reçoivent une réponse 415 au lieu d'être décodées
app.use(express.json({ inflate: false }));

Parmi les neuf autres correctifs, deux concernent le contournement de la vérification du nom d’hôte TLS, et un autre touche crypto.randomUUID() et crypto.randomInt(). Pour ce dernier, l’avis recommande de reconstruire les applications, pas seulement de mettre à jour le binaire.

npm : des vers qui se propagent de paquet en paquet

Le risque Node.js ne se limite pas au moteur. L’année 2026 a vu une série d’attaques automatisées sur le registre npm, de la famille « Shai-Hulud ». La plus large à ce jour, baptisée CHAINDROP, a débuté le 4 août : le compte du mainteneur de keyv, une bibliothèque téléchargée plus de 600 millions de fois par mois, a été compromis. En deux jours, plus de 400 paquets ont été infectés, pour un total de plus d’un milliard de téléchargements mensuels combinés.

Le mode opératoire est le même à chaque vague :

  1. Un paquet infecté contient un script preinstall qui s’exécute pendant npm install, sans aucune action de votre part.
  2. Le script collecte les secrets de la machine : jetons npm et GitHub, clés SSH, identifiants cloud, clés d’API d’outils d’IA.
  3. Avec les jetons npm volés, il republie une version infectée de chaque paquet auquel le mainteneur a accès. C’est ce qui le rend autonome.

Les mesures qui protègent réellement un projet :

  • Bloquer les scripts d’installation. npm 12 le fait par défaut pour preinstall. Sur les versions antérieures, ajoutez ignore-scripts=true dans votre fichier .npmrc et réactivez au cas par cas.
  • Figer les versions avec un fichier de verrouillage versionné et installer avec npm ci, jamais npm install en production.
  • Attendre avant d’adopter une version. Une version publiée depuis quelques jours a eu le temps d’être signalée si elle est malveillante. pnpm propose un réglage de délai minimal avant qu’une nouvelle version soit prise en compte.
  • Activer la double authentification sur tous les comptes npm et GitHub, et refuser les jetons qui la contournent.

Si une machine de développement a installé un paquet compromis, considérez tous ses secrets comme volés : révoquez et régénérez.

Shopify : le tunnel de commande détourné par des applications tierces

Le 10 octobre, un développeur a constaté qu’une boutique Shopify redirigeait ses clients vers une fausse page de paiement au moment de régler. Le cœur de Shopify n’a pas été compromis. L’attaque est passée par des applications installées sur les boutiques, principalement Hulk Product Options, puis Swym Wishlist Plus et Selleasy le 13 octobre.

Le mécanisme est instructif pour toute personne qui gère un site avec des extensions :

  1. Le script de l’application se charge normalement depuis le CDN de Shopify.
  2. Au chargement, il interroge l’API de l’éditeur de l’application, qui renvoie un bloc de code personnalisé.
  3. Ce bloc, modifié par les attaquants, redirige l’acheteur vers un faux tunnel de commande hébergé sur des domaines comme checkout-confirm.top.
  4. La fausse page collecte la carte bancaire, puis renvoie vers le vrai paiement. La commande aboutit, le client ne remarque rien.

Shopify a retiré les applications concernées de sa place de marché et, le 20 octobre, a déployé un changement : la boutique demande désormais confirmation à l’acheteur avant tout renvoi vers un site externe.

Si vous gérez une boutique Shopify, le test prend une minute :

  1. Ouvrez une fenêtre de navigation privée.
  2. Ajoutez un article au panier et cliquez sur Commander.
  3. Vérifiez que l’adresse affichée reste sur votre domaine ou sur shopify.com.

Ensuite : désinstallez les applications que vous n’utilisez plus, changez le mot de passe Shopify et ceux des comptes applicatifs, activez la double authentification, et passez en revue les intégrations qui ont accès à votre boutique. Ce type d’intervention sur Shopify est traité en partenariat avec Huggii, contactez-moi pour en savoir plus.

Ce que ces trois affaires ont en commun

Dans les trois cas, le site lui-même n’était pas la cible initiale. Le point d’entrée était une dépendance : le moteur du langage, une bibliothèque installée, une application tierce. Un site bien codé mais jamais mis à jour reste exposé.

La réponse tient en trois habitudes : connaître ses versions, les mettre à jour dans la semaine qui suit un correctif critique, et limiter ce qu’un script injecté peut faire grâce aux en-têtes de sécurité. Pour ce dernier point, j’ai publié un outil de vérification qui lit les en-têtes de votre site et signale ce qui manque.

Si votre site tourne sur PHP ou Node.js et que vous ne savez pas qui le maintient à jour, c’est le moment de le découvrir. Mon offre de maintenance couvre exactement cela. Parlons-en.