L'équipe de sécurité de PHP avait annoncé deux failles critiques dans l'interpréteur lui-même, et non dans un framework ou un plugin. Elles portent les identifiants CVE-2026-109618 et CVE-2026-109619, sous le nom PHP2Shell. PHP leur attribuait une note de 9,2 selon CVSS v4.0. Des informations diffusées avant le correctif mentionnaient 10,0, sans confirmation.

session.upload_progress.enabled = 0

L'avis CERT-EU 2026-018 décrivait un risque d'exécution de code à distance sans authentification. CERT-EU et l'ACSC australienne estimaient que PHP 5 et les versions suivantes pouvaient être concernés. PHP n'avait pas encore publié de périmètre officiel des versions touchées à la date du rapport. Les correctifs annoncés devaient couvrir PHP 8.2, 8.3, 8.4 et 8.5. Des versions préliminaires citées par plusieurs sources étaient 8.5.12, 8.4.27, 8.3.36 et 8.2.35, sous réserve de confirmation dans l'annonce officielle.

La divulgation a rompu le calendrier habituel des embargos de sécurité. Vers 15 h 20 UTC le 20 octobre, un message anonyme publié sur Hacker News annonçait la divulgation imminente de deux failles RCE critiques dans PHP. Le message a été supprimé, mais des captures ont circulé. L'embargo initial devait apparemment durer jusqu'au 22 octobre. PHP a ensuite avancé la publication au 21 octobre à 14 h UTC, avec la possibilité d'une sortie encore plus rapide en cas d'exploitation active. CERT-EU a publié l'avis 2026-018, watchTowr a reproduit l'une des failles et la vidéo de démonstration d'un chercheur a été retirée.

Les premières analyses ont associé le problème au code de suivi de progression des sessions. À 5 h UTC le 21 octobre, GMO Flatt Security a précisé que le changement de configuration partagé en ligne ne fournissait pas une protection complète et serait probablement contourné. À 7 h 43 UTC, Dane Knecht, directeur technique de Cloudflare, a signalé les premières attaques et indiqué que des règles WAF d'urgence avaient été activées pour tous les clients, y compris les offres gratuites. Huntress, watchTowr et l'ACSC n'avaient pas confirmé d'exploitation observée dans la nature au moment de leurs publications.

Des dépôts de preuve de concept sont apparus sur GitHub en quelques heures. Certains servaient à vérifier la présence de la faille, d'autres prétendaient fournir des exploits fonctionnels. Au moins un audit indépendant a conclu que le code d'exploitation diffusé ne fonctionnait pas. Dès qu'un correctif est disponible, les attaquants peuvent comparer le code corrigé à l'ancienne version. Sansec s'attendait donc à une vague d'attaques dans les minutes suivant la publication.

La surface d'attaque supposée concerne le traitement des données de formulaires multipart par l'exécution PHP. Ce format est utilisé pour les envois de fichiers et est analysé avant le démarrage du code applicatif. Si cette analyse est exacte, les contrôles de connexion, la protection CSRF et la validation des fichiers arrivent trop tard. Désactiver les envois de fichiers PHP ne suffit pas nécessairement à empêcher l'analyse d'une requête multipart. Toute page qui accepte des données POST pourrait être concernée, pas seulement un formulaire d'envoi. PHP n'avait pas confirmé la cause précise, et les chercheurs divergeaient sur le composant vulnérable. Leur conseil commun était de corriger ou de mettre PHP à niveau.

Le contournement le plus diffusé était `session.upload_progress.enabled = 0`. GMO Flatt a ensuite indiqué que ce réglage ne suffisait pas. Un autre chercheur estimait que la seconde faille restait accessible par l'analyseur multipart, quelle que soit cette option. Joe Ferguson, responsable de PHP 8.6, a lui aussi déconseillé de compter sur les réglages INI. L'option est PHP_INI_PERDIR et ne peut donc pas être modifiée à l'exécution avec `ini_set()`. Une modification faite dans la configuration CLI plutôt que dans le pool PHP-FPM, ou placée dans `.user.ini` sous mod_php, peut rester sans effet. La désactivation supprime l'indicateur de progression des envois et peut ajouter une couche de protection, mais elle ne résout pas l'incident.

Le principal risque concerne les branches qui ne sont plus maintenues. PHP 8.1 est arrivé en fin de vie en décembre 2025, PHP 8.0 en novembre 2023. Les branches PHP 7.x et 5.x avaient cessé d'être supportées auparavant. Si les failles remontent bien à PHP 5, ces installations ne recevront aucun correctif du projet PHP. Une analyse Shodan réalisée par Mallory le 20 octobre a recensé environ 1,5 million d'hôtes exposés qui annonçaient une version PHP. Environ 884 000 d'entre eux, soit 59 %, utilisaient une branche sans correctif prévu. La répartition estimée était de 369 000 hôtes en PHP 5.x, 329 000 en 7.x et 186 000 en 8.0 ou 8.1. Quelque 740 000 autres hôtes masquaient leur version. L'exposition réelle est donc probablement supérieure. Ces bannières ne constituent pas un décompte des systèmes vulnérables.

Les mêmes données comptaient environ 53 600 hôtes PHP en Inde. Parmi ceux qui publiaient une version, près de 19 800 utilisaient une branche sans correctif prévu. Les bannières ne permettent pas d'identifier les opérateurs. Les installations anciennes correspondent souvent à des portails abandonnés, à des sites de petites entreprises ou à des environnements d'hébergement mutualisé restés en place pendant des années.

Les responsables d'une branche en fin de vie disposent de plusieurs mesures concrètes. Ils peuvent migrer vers une version supportée, obtenir un correctif rétroporté auprès de leur distribution ou de leur hébergeur, retirer le système de l'internet public derrière un VPN ou une liste d'autorisation, ou le mettre hors ligne. Les distributions d'entreprise et certains hébergeurs maintiennent parfois d'anciens paquets selon leur propre calendrier. Il faut donc vérifier la CVE dans leur avis de sécurité, plutôt que se fier uniquement au numéro de version. CERT-EU recommande la mise hors ligne lorsqu'aucun correctif n'est possible.

La première étape consiste à inventorier chaque environnement PHP, notamment PHP-FPM, Apache mod_php, CGI, les conteneurs, les runners CI, cPanel, Plesk, XAMPP et les appliances qui embarquent PHP. Les systèmes exposés et ceux qui utilisent PHP 8.1 ou une version antérieure doivent être traités en urgence. L'upgrade doit être préparé et la personne autorisée à déclencher un redémarrage doit être identifiée. Les utilisateurs de Cloudflare doivent configurer les règles gérées pour bloquer le trafic, pas seulement le journaliser, et empêcher l'accès direct à l'origine.

Après la publication, les branches supportées doivent être corrigées immédiatement via php.net ou l'avis de la distribution. Il faut redémarrer PHP-FPM, Apache, Laravel Octane et les workers de file d'attente, car les processus persistants conservent l'ancien interpréteur en mémoire. La vérification doit porter sur le processus qui sert réellement les requêtes, et pas uniquement sur la sortie de `php -v` dans le shell. Les clients d'un hébergement administré doivent demander à leur fournisseur quand le paquet corrigé sera disponible.

La recherche d'incident doit couvrir les fichiers PHP nouveaux ou modifiés dans les racines web et les répertoires d'envoi, les nouveaux administrateurs CMS, les connexions sortantes inhabituelles et les workers PHP qui s'arrêtent. Des tentatives d'exploitation échouées peuvent provoquer le crash d'un worker. Une hausse des erreurs 5xx sur les requêtes POST mérite donc une analyse. Un serveur exposé utilisant une branche en fin de vie doit être considéré comme potentiellement compromis jusqu'à vérification. Les identifiants, clés API et rôles cloud présents sur cette machine devront ensuite être renouvelés.