PHP2Shell : ce qui s’est passé avec PHP cette semaine.

Mercredi 21 octobre, l’équipe de PHP a publié en urgence des correctifs pour deux failles critiques : CVE-2026-109618 et CVE-2026-109619, qu’on appelle déjà « PHP2Shell ». Comme PHP fait partie de mon…

  • 6 min de lecture

Mercredi 21 octobre, l’équipe de PHP a publié en urgence des correctifs pour deux failles critiques : CVE-2026-109618 et CVE-2026-109619, qu’on appelle déjà « PHP2Shell ». Comme PHP fait partie de mon quotidien (la plupart des sites que je développe tournent dessus), je vous explique ce qu’il en est, ce que j’ai fait sur mes serveurs, et comment vérifier de votre côté.

En bref

  • Deux failles dans le moteur même de PHP. Elles ne viennent ni de WordPress, ni d’une extension, ni d’un site en particulier.
  • Elles permettent d’exécuter du code à distance sans être authentifié, autrement dit de prendre la main sur le serveur.
  • Gravité : 9,2 sur 10 pour chacune.
  • Versions corrigées : 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
  • Toutes les façons de faire tourner PHP sur un serveur web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed… Être « en FPM » ne protège pas.

Les deux failles, un peu plus en détail

CVE-2026-109618 touche la gestion du manque de mémoire. Quand PHP manque de mémoire en plein traitement d’une requête, il s’arrête net, en laissant certaines données internes à moitié initialisées. Un attaquant qui sait provoquer cette situation au bon moment peut corrompre la mémoire et faire exécuter son propre code.

CVE-2026-109619 est un problème d’état qui survit d’une requête à l’autre. Des informations restent référencées alors que la mémoire qui les contenait a déjà été libérée (ce qu’on appelle un « use-after-free »). Le chemin d’attaque confirmé passe par le suivi de progression des envois de fichiers. Les conséquences : fuite de mémoire, et exécution de code avec les droits du processus qui fait tourner PHP.

Dans les deux cas, l’attaquant n’a besoin ni de compte ni de mot de passe.

Comment elles ont été découvertes

Ce sont des chercheurs en sécurité qui les ont trouvées : Ryan Austin chez Calif, l’équipe de Wiz Research, et OpenAI, ce qui veut dire que l’intelligence artificielle a aussi contribué à la recherche. Les premiers signalements à l’équipe de PHP remontent à août. La suite s’est déroulée comme il se doit : on prépare les correctifs discrètement, et on n’annonce qu’une fois la réparation prête.

Une fuite, et la journée s’est emballée

Mardi 20 octobre, la veille de la publication prévue, les références des failles ont fuité sur Hacker News et les réseaux sociaux. L’équipe de PHP a avancé son annonce, et les correctifs sont sortis le mercredi.

Ensuite, tout est allé très vite :

  • le CERT-FR (ANSSI) a publié une alerte et un avis le jour même ;
  • le CERT-EU a fait de même pour les institutions européennes ;
  • l’agence américaine CISA a appelé à corriger immédiatement.

Sur les attaques réelles, les informations divergent. watchTowr dit avoir observé des tentatives d’exploitation des deux failles, mais pas de tentative réussie, et Cloudflare a lui aussi signalé des premières tentatives. Dans le doute, tout le monde est d’accord sur un point : il faut mettre à jour sans attendre.

Vous avez peut-être remarqué de nombreux sites en maintenance ces derniers jours. C’était sans doute ça : leurs responsables installaient la correction.

Ce que j’ai fait

Sur mon serveur perso (Docker), deux conteneurs faisaient tourner une version vulnérable : le moteur PHP de mes sites (nginx + PHP-FPM) et un outil d’administration interne (Apache + mod_php, non accessible depuis Internet). Je suis passé de 8.2.31 à 8.2.35 pour le premier, et de 8.3.31 à 8.3.36 pour le second.

Ma façon de faire :

  1. Télécharger les nouvelles images sans rien arrêter, et vérifier la version qu’elles contiennent avant de les déployer :
    docker pull php:8.2-fpm
    docker run –rm php:8.2-fpm php -v
  2. M’assurer que personne n’était en train d’utiliser les services. J’héberge entre autres un jeu en ligne : j’ai attendu qu’aucune partie ne soit en cours.
  3. Recréer uniquement les conteneurs concernés :
    docker compose up -d –no-deps
  4. Contrôler le résultat : version de PHP, extensions, affichage des pages, tests automatiques.

L’interruption a duré environ une minute, le temps que PHP réinstalle ses extensions.

Pour les sites de mes clients, WordPress compris, l’hébergeur a appliqué la correction de son côté. J’ai vérifié que la version en service est bien à jour. Aucun de mes clients n’est concerné.

Comment vérifier de votre côté

  • Hébergement mutualisé : regardez la version de PHP dans votre espace d’administration (sur cPanel, le « Sélecteur de version PHP »).
  • Serveur ou VPS : php -v. Attention, le PHP utilisé par le serveur web (FPM, module Apache) n’est pas forcément celui de la ligne de commande. Vérifiez les deux.
  • Docker : docker exec php -v.
  • Paquets Debian, Ubuntu, Red Hat… : les distributions intègrent souvent le correctif sans changer le numéro de version. Fiez-vous au bulletin de sécurité de votre distribution.

Vous ne pouvez pas mettre à jour tout de suite ? PHP propose un réglage provisoire : session.upload_progress.enabled = 0, à placer dans le php.ini ou la configuration FPM. Mais attention, il ne réduit le risque que pour une seule des deux failles. Seule la mise à jour corrige vraiment le problème.

Vous êtes en PHP 8.1 ou plus ancien ? L’équipe de PHP ne publie plus de correctif pour ces versions. Le CERT-FR recommande d’isoler ces serveurs et de migrer vers une version maintenue. Selon votre installation, votre distribution Linux ou votre prestataire de support peut aussi proposer un correctif.

Vous avez un doute ? Je peux vérifier pour vous

Tout le monde n’a pas le temps, ni l’envie, d’aller fouiller dans les réglages d’un hébergement ou d’un serveur. Si vous avez un site, une boutique ou une application en PHP et que vous n’êtes pas sûr d’être à l’abri, je peux faire le point avec vous.

Ce que je vérifie :

  • la version de PHP réellement utilisée par votre site, et la présence du correctif ;
  • votre exposition : comment PHP est installé, et quels outils d’administration sont accessibles depuis Internet alors qu’ils ne devraient pas l’être ;
  • le reste de la chaîne : WordPress, ses extensions, son thème, et les versions qui ne sont plus maintenues ;
  • les bases : sauvegardes, accès d’administration, certificats.

Mutualisé, VPS ou serveur perso, je m’adapte.

👉 Demandez votre vérification (https://nlion.fr/contact/), je vous réponds rapidement.

Sources

Officielles

Pour aller plus loin

À lire ensuite

D’autres articles du même sujet : Actualités.