Deux vulnérabilités critiques dans le moteur PHP ont poussé des préfectures, des ministères européens et même un opérateur télécom à couper leurs sites par précaution. Exploitable en théorie sur une immense partie du Web, PHP2Shell se révèle plus capricieuse sur le terrain. Ce n’est pas une raison pour baisser la garde, surtout pour qui fait encore tourner PHP 8.1.

Mercredi 21 octobre, 9 h 43, heure de Paris. Cloudflare voit affluer les premières attaques contre des serveurs PHP, six heures avant la sortie des correctifs officiels. Ses règles de filtrage tournaient déjà depuis 3 h 02 UTC. Amazon affirme pour sa part avoir repéré des tentatives dès le 17 octobre, avant toute divulgation.

En cause, une fuite sur Hacker News le 20 octobre, alors que le projet PHP travaillait en coulisses depuis l’été. Calif, partenaire d’OpenAI dans le programme Patch the Planet, avait signalé la première faille le 11 août, débusquée avec le modèle GPT-5.6 Sol ; Wiz a transmis la seconde le 24 août. La divulgation coordonnée a tourné à la course contre la montre.

Une mémoire qui ne fait pas le ménage

Référencées CVE-2026-109618 et CVE-2026-109619, les deux failles affichent un score CVSS v4 de 9,2. La première tient à la gestion des pénuries de mémoire ; la seconde, à des « notes » internes jamais effacées. Mises bout à bout, elles produisent un scénario redouté : après un plantage, PHP ne nettoie pas la zone mémoire que réutilisera la requête suivante. Un attaquant peut alors y glaner des fragments laissés par d’autres visiteurs (mots de passe, jetons de session, clés d’API), voire exécuter du code à distance, sans compte ni interaction de l’utilisateur.

Deux détails aggravent le diagnostic. Le code fautif remonte à PHP 5.4, et la configuration par défaut est exposée. WordPress, Drupal, Joomla ou Magento ne protègent en rien, même parfaitement à jour, puisque le défaut se loge sous l’application, dans le moteur lui-même. Selon le projet PHP, certaines configurations autorisent l’attaque avant que le code applicatif ne s’exécute.

Redoutable sur le papier, capricieuse en production

Faut-il pour autant imaginer 70 % du Web à la merci du premier venu ? L’exploitation repose sur un duo de requêtes : un « producteur » qui altère l’état mémoire du serveur, puis un « consommateur » qui en tire profit. Encore faut-il que les deux tombent sur le même worker PHP. Derrière un répartiteur de charge ou face à un grand nombre de processus, cette affinité devient une loterie.

Le mode d’exécution change aussi la donne. Avec mod_php sous Apache, la chaîne complète jusqu’à l’exécution de code est confirmée. Avec PHP-FPM ou CGI, en revanche, la requête piégée fait tomber le worker dès son démarrage : l’attaque se réduit alors à un déni de service. Le chercheur Daniel Card a recensé une huitaine de conditions à réunir pour chaque cible et parle d’un véritable parcours d’obstacles. Pour une large part des serveurs, le risque réaliste serait donc l’indisponibilité, parfois la fuite d’informations, plus rarement la prise de contrôle.

Une tentative ratée laisse d’ailleurs des traces dans les journaux : workers qui s’effondrent, erreurs 500 en rafale, processus recyclés à un rythme inhabituel.

Couper d’abord, vérifier ensuite

Pourquoi tant d’organisations ont-elles préféré l’écran noir ? Parce qu’on ne vérifie pas une huitaine de conditions une à une sur un serveur exposé. À la demande de l’ANSSI, des préfectures ont été mises hors ligne. Météo France, la CNIL, Santé publique France et l’Ademe ont suivi, tandis qu’Orange suspendait temporairement certains services le temps de déployer les correctifs. Hors de nos frontières, le réflexe a été le même : portails néerlandais et finlandais, gouvernements belge, danois, hongrois et letton, Länder de Hesse et de Bade-Wurtemberg, ville d’Édimbourg, État de Neuchâtel…

Côté cloud, Google a actualisé App Engine standard et Cloud Run, tout en demandant à ses clients de reconstruire leurs conteneurs et d’abandonner les runtimes PHP 8.1 et antérieurs. Les hébergeurs mutualisés s’en remettent à des protections provisoires comme Imunify360.

Ce qui attend les équipes cette semaine

Première urgence : passer en 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 selon la branche, en commençant par tout ce qui est exposé sur Internet. Le plus délicat reste de savoir où PHP tourne vraiment : au-delà des CMS, il se niche dans des consoles réseau, des systèmes de vidéosurveillance ou de gestion technique de bâtiment. L’éditeur de GLPI a corrigé son offre cloud dès le 21 octobre, mais les instances auto-hébergées dépendent de la mise à jour du PHP du serveur.

Corriger ne suffit pas. Un correctif n’efface pas un web shell déposé la veille, rappelle le NCSC britannique. Fichiers inattendus, connexions sortantes douteuses, comptes créés récemment : la chasse aux indices s’impose sur les machines exposées avant le 21 octobre et si des données personnelles ont fuité, l’horloge RGPD tourne, avec 72 heures pour notifier l’autorité.

Quand la mise à jour est impossible dans l’immédiat, les palliatifs ne se valent pas. Désactiver session.upload progress ne suffit pas à lui seul, et le mode maintenance d’un CMS ne protège rien. Bloquer les requêtes multipart/form-data au niveau du serveur web ou du WAF réduit l’exposition, sans remplacer le correctif, insiste l’équipe PHP. En dernier recours, la mise hors ligne reste l’option la plus sûre.

L’éléphant dans la salle serveur

Reste la question qui fâche : PHP 8.1 et les branches plus anciennes ne disposeront pas de correctif officiel. Toute promesse de rétroportage par un tiers mérite donc une confirmation écrite. Pour beaucoup de DSI, PHP2Shell transforme une dette technique tolérée en risque immédiat.

L’épisode laisse aussi entrevoir l’avenir. Une IA a contribué à dénicher une faille vieille de plus de dix ans, et une fuite a suffi à réduire le délai entre divulgation et attaque à quelques heures. Dans ce nouveau tempo, l’inventaire à jour et la capacité à patcher vite deviennent des sujets stratégiques, et plus seulement des tâches d’exploitation.