PHP2Shell : le correctif est publié, mettez à jour avant que les bots ne passent

Seize heures, montre en main. PHP a publié ce mercredi 21 octobre à 16h (heure de Paris) les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP, c’est le langage qui fait tourner environ trois sites web sur quatre, dont tous les WordPress. Ces versions bouchent les deux failles critiques annoncées ce matin sous le nom PHP2Shell. En clair, n’importe qui peut prendre la main sur un serveur touché, sans aucun mot de passe. Cloudflare filtrait déjà les tentatives depuis 5h du matin. Mais les attaquants modifient déjà leur méthode pour contourner ses règles, d’après l’entreprise. Vous hébergez un site WordPress, une boutique WooCommerce qui accepte le bitcoin ou le tableau de bord de votre pool de minage ? Alors le reste de cette page peut attendre, pas la mise à jour.

Correctif PHP2Shell : qui est couvert, qui ne l’est pas

Une faille, c’est une erreur dans le code. Un pirate peut s’en servir pour faire faire au serveur ce qu’il veut. L’avis de sécurité de php.net en décrit deux, référencées CVE-2026-109618 et CVE-2026-109619. Toutes deux affichent la note de 9,2 sur 10 sur l’échelle de gravité CVSS. Dans les deux cas, l’attaquant envoie une requête piégée au serveur. Il obtient ensuite le droit de lancer ses propres programmes sur la machine, sans identifiant ni mot de passe. Et cela se produit avant même que le site n’ait commencé à travailler. Le problème touche toutes les façons courantes de faire tourner PHP (PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed). Mais PHP juge le risque maximal sur Apache avec mod_php, car une seule requête y suffit.

Les versions 8.1 et plus anciennes ne reçoivent plus de mises à jour officielles. Pourtant, le projet ne les a pas abandonnées, contrairement à ce que disaient les premières analyses. Il a d’ailleurs mis en ligne sur GitHub des correctifs pour PHP 7.4, 8.0 et 8.1. De même, les distributions Linux et les éditeurs de support étendu avaient reçu les patchs à l’avance. Si vous ignorez quelle version vous utilisez, votre hébergeur gère sans doute PHP à votre place. Dans ce cas, c’est à lui d’appliquer la mise à jour. Une seule question suffit donc : « Avez-vous appliqué le correctif PHP2Shell ? »

Les rustines temporaires, en attendant la mise à jour

Certains ne peuvent pas mettre à jour dans l’heure. Pour eux, php.net liste des mesures de contournement, autrement dit des rustines temporaires. Le projet précise toutefois qu’« il n’existe pas d’atténuation complète ». La plus efficace consiste à désactiver le suivi des téléversements (le réglage session.upload_progress.enabled passé à 0). Il faut ensuite redémarrer PHP, puis réduire la taille maximale des données qu’un visiteur peut envoyer. Cloudflare, qui filtre le trafic d’une bonne partie du web, a aussi activé ses règles de blocage. Elles s’appliquent à tous ses abonnements, gratuit compris, depuis 5h02 heure de Paris, soit neuf heures avant la divulgation. L’entreprise en a d’ailleurs profité pour lancer une nouvelle brique d’analyse. Celle-ci inspecte à la fois ce qui entre sur le serveur et ce qui en sort.

Ce que vous devez faire aujourd’hui, dans l’ordre :

D’abord, lister toutes vos installations PHP, y compris celles cachées dans un logiciel tiers (outil de statistiques, forum, vieux site oublié).

Ensuite, passer en 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 selon votre version, ou installer le paquet de votre distribution Linux.

Sur une version trop ancienne, appliquer les rustines ci-dessus et planifier la migration. PHP 8.2 s’arrête aussi le 31 décembre.

Enfin, surveiller les signes d’attaque. Par exemple des envois de fichiers suivis d’erreurs 500 en série, des cookies PHPSESSID anormalement gros ou des processus PHP qui redémarrent sans raison.

Une faille vieille de dix ans, trouvée par une IA en une semaine

Le billet de Wiz Research répond à la question que tout le monde se posait depuis la fuite de lundi. Cette entreprise de cybersécurité est à l’origine de la découverte. En fait, les bugs dormaient dans le moteur de PHP depuis plus de dix ans. Ce qui a changé, c’est l’outillage. L’équipe de Sagi Tzadik, Shir Tamari, Nir Ohfeld et Tomer Schwartz a trouvé la première faille le 19 août. Elle s’est appuyée sur son outil Wiz Atlas et deux IA récentes, Gemini 4 Argon de Google et GPT-5.6 Sol d’OpenAI. Dès le lendemain, l’équipe confirmait la prise de contrôle à distance sur Drupal, puis sur WordPress le surlendemain. Le rapport est parti chez PHP le 24 août. L’accusé de réception est arrivé le 21 septembre. Le correctif, lui, tombe deux mois jour pour jour après le signalement.

Wiz l’écrit sans détour. « Un seul chercheur a accompli en une semaine » le travail de plusieurs mois d’une équipe de haut niveau. Car les modèles adaptent l’attaque à chaque version de PHP, à chaque configuration et à chaque disposition de la mémoire. L’entreprise compare donc l’épisode à Heartbleed en 2014 et à Log4Shell en 2021, deux failles qui avaient secoué tout internet. Elle parle même d’un point de bascule pour l’ère de l’intelligence artificielle offensive. Raluca Ada Popa, responsable de la sécurité de Gemini chez Google DeepMind, nuance l’argument dans le même billet. En effet, l’IA a aussi servi à valider le correctif et à construire les outils de détection.

Un embargo qui a sauté deux jours trop tôt

La coordination a mobilisé le projet PHP, Calif.io, OpenAI et Quarkslab pour la recherche. Puis Automattic (la maison mère de WordPress.com), Akamai, AWS, Cloudflare, Fastly, Google, Imperva, Microsoft et Vercel ont pris le relais pour les protections. Détail amusant relevé sur X par le chercheur Ananay Arora, quelqu’un a déposé le domaine php2shell.com le 14 octobre. Soit une semaine avant la divulgation. Moins amusant, l’embargo prévu jeudi a sauté lundi matin, après un message sur le forum Hacker News. Une vidéo de démonstration a même circulé avant d’être retirée. Huntress n’avait pourtant vu aucune exploitation réelle lundi soir. Cloudflare en voit en revanche depuis ce matin.