PHP2Shell : quelques heures entre la fuite et l'attaque. Votre hébergeur veillait-il ?

Le 21 octobre, l'équipe de PHP a publié en urgence quatre nouvelles versions pour corriger deux failles critiques dans le cœur du langage. Elles permettent d'exécuter du code sur un serveur sans compte ni mot de passe, parfois avant même que l'application ne démarre. PHP fait tourner WordPress, Drupal, Joomla, une grande partie des boutiques en ligne et des sites de mairies. Voici ce qui s'est passé, comment savoir si vous êtes concerné, et ce qu'il faut faire cette semaine.

Une semaine en accéléré #

• 24 août. Les chercheurs de Wiz signalent les failles à l'équipe de sécurité de PHP. La société Calif et OpenAI les trouvent aussi de leur côté. Les trois équipes ont travaillé avec des modèles d'intelligence artificielle.
• 17 octobre. Amazon indique avoir repéré, sur ses serveurs pièges, une tentative d'exploitation datée de ce jour-là, quatre jours avant l'annonce publique.
• 20 octobre. La date de divulgation prévue, le 22, fuite sur Hacker News avec les numéros des failles. Le soir même, PHP avance la publication au lendemain, 14 h UTC.
• 21 octobre. Sortie de PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Le jour même, watchTowr observe les premières attaques sur son réseau de pièges.
• 22 octobre. Le CERT-FR a connaissance de preuves de concept et constate des tentatives d'exploitation.
• 23 octobre. PHP signale une troisième faille, CVE-2026-115560, qui ne touche que des configurations rares.
• 26 octobre. L'agence américaine CISA inscrit les deux failles à son catalogue des failles activement exploitées.

Entre la fuite et les premières attaques observées, il s'est écoulé quelques heures. Sur les serveurs que nous hébergeons, quelqu'un regardait.

Pourquoi c'est grave : la faille n'est pas dans votre code #

D'habitude, une faille web se trouve dans une extension WordPress, un formulaire mal protégé ou une bibliothèque oubliée. Ici, elle se trouve dans le moteur qui exécute le code : CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10. Dit simplement, il y a deux mécanismes.

• La mémoire saturée au mauvais moment. Quand PHP manque de mémoire en pleine lecture d'une requête, par exemple pendant l'envoi d'un fichier, il s'interrompt avec des données à moitié préparées. Le nettoyage qui suit les traite ensuite comme valides.
• Les restes de la requête précédente. Une requête peut laisser derrière elle un état interne qui pointe vers une mémoire déjà libérée. La requête suivante, traitée par le même processus, s'en sert avant qu'il ne soit remis à zéro.

D'après Wiz, ces défauts remontent à plus de dix ans : toutes les versions depuis PHP 5.4 sont touchées par au moins l'une des deux failles. Wiz a obtenu l'exécution de code sur les dernières images de WordPress, Drupal et Joomla. Même une simple page « Hello World » est vulnérable, puisque l'application n'entre pas en jeu. Autre risque : la lecture à distance de la mémoire du serveur, où peuvent se trouver des mots de passe, des clés d'API ou des certificats.

PHP juge le risque le plus élevé pour Apache avec mod_php. Là, une seule requête sans authentification suffit à déclencher l'attaque avant que le code du site ne s'exécute. Palo Alto Networks recense plus de 22,6 millions d'instances exposées potentiellement vulnérables.

Êtes-vous concerné ? #

Oui, si un serveur exécute PHP pour répondre à des visiteurs, quelle que soit la façon dont il tourne : PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ou LiteSpeed.

• PHP 8.2, 8.3, 8.4 et 8.5 : corrigées en 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
• PHP 7.4, 8.0 et 8.1 : plus suivies par le projet. Correctifs de votre distribution ou de votre fournisseur, ou migration.
• PHP 7.3 et plus anciennes, PHP 5 compris : aucun correctif. La migration est obligatoire.

Deux pièges reviennent souvent.

• PHP se cache dans d'autres produits. On le trouve dans des panneaux d'hébergement, des appareils réseau, des logiciels métier. La CISA le rappelle : il n'est pas toujours visible.
• La version qui sert le site n'est pas forcément celle qu'on croit. Un serveur peut avoir plusieurs versions installées. Demandez à votre prestataire laquelle répond vraiment aux visiteurs.

Ce qu'il faut faire cette semaine #

1. Mettre à jour PHP lui-même, pas seulement WordPress ou les extensions. Les distributions Linux ont reçu les correctifs à l'avance, et leurs paquets sont disponibles.
2. Redémarrer tous les processus PHP après la mise à jour. Sinon, l'ancien code reste en mémoire et le serveur reste vulnérable, même avec le bon paquet installé.
3. Ne pas compter sur les réglages de contournement. L'équipe de PHP le dit elle-même : aucun ne rend une installation sûre, seule la mise à jour corrige. Une exception : pour la troisième faille, désactiver session.upload_progress suffit en attendant la prochaine version.
4. Isoler ce qui ne peut pas être mis à jour. C'est la consigne du CERT-FR pour les branches qui ne sont plus suivies : couper l'accès depuis internet, puis migrer. Notez aussi que PHP 8.2 ne recevra plus de correctifs après le 31 décembre 2026.
5. Regarder les journaux. Signes à surveiller selon Wiz et la CISA : des envois de formulaires inhabituels suivis d'erreurs de mémoire ou de séries d'erreurs 500, des cookies de session anormalement longs, des processus PHP qui redémarrent sans raison, ou qui lancent des commandes et téléchargent des outils.
6. Changer les secrets si le serveur était exposé avant la mise à jour. Une mise à jour ferme la porte, elle ne fait pas sortir quelqu'un qui serait déjà entré. Et la mémoire a pu laisser fuir des mots de passe ou des clés.

Ce que cette semaine dit de l'hébergement #

Chaque langage a eu, ou aura, sa semaine comme celle-ci. La bonne question n'est pas de savoir si PHP est sûr. Elle est de savoir qui surveille vos serveurs, et en combien de temps le correctif y arrive.

Pour les applications que nous hébergeons et maintenons, le socle est tenu à jour et surveillé jour et nuit, sur nos serveurs en France. Une alerte comme celle-ci se traite chez nous, sans que vous ayez à nous appeler : correctif appliqué, contrôle après coup, sauvegardes de chaque nuit à disposition.

Votre site ou votre application PHP est chez un autre prestataire, ou tourne sur une version qui n'est plus suivie ? Nous pouvons faire le point avec vous : ce qui est exposé, ce qui doit être mis à jour, et s'il le faut un plan de migration ou une reprise en maintenance.

Sources #

• PHP, annonces de sécurité des 20, 21 et 23 octobre 2026 : versions corrigées, avis CVE-2026-109618 et CVE-2026-109619, avis informatif sur CVE-2026-115560.
• CERT-FR, bulletin CERTFR-2026-ALE-014, Multiples vulnérabilités dans PHP (20 octobre 2026, mis à jour le 26).
• CERT-EU, avis de sécurité 2026-018, Critical Vulnerabilities in PHP (23 octobre 2026).
• CISA, Critical Vulnerabilities in PHP Require Immediate Patching (21 octobre 2026, mise à jour du 26 : inscription au catalogue KEV).
• Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities (21 octobre 2026).
• watchTowr, PHP2Shell FAQ : chronologie et exploitation observée.
• Unit 42 (Palo Alto Networks), Threat Brief: PHP2Shell (mis à jour le 25 octobre 2026).
• The Hacker News, tentative d'exploitation quatre jours avant la divulgation, d'après Amazon.