Faille PHP : les impôts hors ligne et 1,9 million de serveurs exposés

Mardi 20 octobre, deux identifiants de vulnérabilité fuitent sur Hacker News avant l'heure prévue. Mercredi en fin d'après-midi, l'équipe PHP publie ses correctifs en catastrophe. Jeudi, le site des impôts, celui de plusieurs préfectures, Météo-France et la mairie de Toulouse affichent toujours une page de maintenance. La faille PHP baptisée php2shell n'a pas provoqué de fuite de données spectaculaire pour l'instant — elle a surtout obligé une partie de l'administration française à se débrancher d'Internet pendant trois jours.

Ce qui s'est réellement passé entre le 17 et le 22 octobre

La chronologie vaut le détour, parce qu'elle raconte un ratage.

• 17 octobre : Amazon Threat Intelligence observe des tentatives d'exploitation sur son réseau de pots de miel. Quatre jours avant la divulgation publique. Quelqu'un savait déjà.
• 20 octobre : les identifiants CVE-2026-109618 et CVE-2026-109619 circulent sur les réseaux sociaux et Hacker News, en avance sur l'embargo convenu entre chercheurs et éditeur.
• 21 octobre : PHP publie ses avis de sécurité et les versions corrigées. L'ANSSI recommande dans la foulée de sortir les serveurs concernés du réseau jusqu'à l'installation de la mise à jour.
• 22 octobre : Amazon confirme que php2shell est désormais largement exploité, avec des charges utiles qui laissent penser à plusieurs groupes distincts.

Entre-temps, les équipes informatiques des collectivités ont fait ce qu'on leur a dit : débrancher. D'où les pages blanches. Ce n'est pas un piratage massif, c'est une mise à l'abri. La nuance est importante, même si pour l'usager qui veut consulter son avis d'imposition, le résultat est identique.

Les perturbations n'ont rien de franco-français : des sites publics néerlandais, finlandais, britanniques, allemands, danois et belges ont connu le même sort.

Deux bugs de mémoire, zéro mot de passe requis

Les deux failles sont notées 9,2 sur 10 en CVSS 4.0, et surtout elles sont non authentifiées : pas besoin de compte, pas besoin d'être déjà dans la place. Une requête HTTP bien construite suffit.

• CVE-2026-109618 : quand PHP tombe à court de mémoire, il sort de la situation avec un longjmp(). Problème, ce saut peut interrompre le moteur alors que les données de la requête ne sont que partiellement initialisées. L'attaquant obtient de la mémoire corrompue traitée comme valide.
• CVE-2026-109619 : un use-after-free. PHP conserve un état global qui pointe vers de la mémoire appartenant à une requête. Si cet état n'est pas remis à zéro avant la libération, une requête ultérieure réutilise un pointeur mort.

Mises bout à bout, les deux donnent une chaîne d'exécution de code à distance — celle qu'a démontrée le chercheur Kirill Firsov, en créditant LCFR de Calif.io. Les équipes de Calif.io et de Wiz ont signalé les problèmes de façon coordonnée.

Tous les modes d'exécution ne sont pas logés à la même enseigne : PHP-FPM, php-cgi, FrankenPHP et LiteSpeed sont concernés, mais c'est Apache mod_php qui présente le risque le plus élevé.

Les chiffres

• 1,3 à 1,9 million d'hôtes exposés sur Internet feraient tourner une version vulnérable.
• 69,3 % des sites web dont le langage serveur est identifiable tournent sous PHP.
• Plus de 600 000 serveurs PHP recensés sur l'infrastructure française.
• Versions corrigées : 8.5.12, 8.4.27, 8.3.36, 8.2.35.
• Versions abandonnées à leur sort : de PHP 5.4.0 à 8.1.x, sans correctif.

Ce dernier point est le vrai sujet. WordPress, Drupal, Joomla, Magento : derrière ces noms, il y a des dizaines de milliers de sites d'associations, de cabinets, de commerces, installés il y a six ans et jamais remis à jour depuis. Un hébergement mutualisé en PHP 7.4 n'aura pas de rustine. Jamais.

Pourquoi on ne corrige pas PHP 7

La réponse est désagréable mais logique : PHP 7.4 est en fin de vie depuis fin 2022. Maintenir un correctif de sécurité sur une branche morte, c'est entretenir l'illusion qu'on peut rester dessus. Le projet PHP a choisi la ligne dure.

Sauf que la réalité des hébergeurs ne suit pas. Passer un site de PHP 7.4 à 8.2, ce n'est pas cocher une case : des extensions cassent, des fonctions supprimées font planter des plugins, un thème acheté en 2019 refuse de démarrer. Beaucoup de sites tournent encore sur d'anciennes branches précisément parce que la migration coûte une journée de développeur que personne n'a budgétée.

php2shell transforme cette dette technique en porte d'entrée.

L'IA des deux côtés de la barrière

Détail qui mérite d'être relevé : les deux équipes de chercheurs ont utilisé des modèles d'IA dans leur travail de découverte, courant août. L'audit de code mémoire sur une base aussi ancienne que celle de PHP est exactement le genre de tâche ingrate où une machine qui ne se fatigue jamais fait la différence.

La contrepartie saute aux yeux : si l'analyse automatisée accélère la découverte côté défense, elle l'accélère tout autant côté attaque. La fenêtre entre publication d'un correctif et exploitation de masse se compte désormais en heures. Ici, elle était même négative — l'exploitation a précédé la divulgation de quatre jours.

Ce qu'il faut faire, concrètement

Si vous avez un site :

• Demandez à votre hébergeur la version de PHP réellement active. Pas celle du panneau d'administration, celle du serveur.
• Si c'est 8.2, 8.3, 8.4 ou 8.5 : vérifiez que le numéro de patch est au moins celui de la liste ci-dessus.
• Si c'est 7.x ou 5.x : il n'y a pas de correctif. La seule sortie est la migration, et elle devient urgente.
• Regardez les logs d'accès autour du 17 octobre. Des requêtes anormalement lourdes, des erreurs 500 en rafale, des fichiers PHP apparus dans un répertoire d'upload sont des signaux.
• Changez les identifiants d'administration et les clés d'API après avoir corrigé, pas avant.

Pour un site institutionnel, la coupure préventive est défendable. Pour un commerce qui vit de son site, trois jours hors ligne coûtent cher — d'où l'intérêt, en amont, d'un hébergement maintenu à jour par quelqu'un dont c'est le métier.

Les zones d'ombre

Personne n'a encore publié de bilan des compromissions réussies. On sait qu'il y a exploitation active, on ne sait pas combien de serveurs sont tombés, ni ce qui en a été tiré. Les premiers rapports d'incident arriveront dans les semaines qui viennent, quand les équipes auront fini de relire leurs journaux.

Deuxième inconnue : la fuite d'embargo. Les identifiants CVE se sont retrouvés en ligne avant la date convenue, ce qui a offert aux attaquants une longueur d'avance supplémentaire. Qui a parlé, et pourquoi, reste à éclaircir.

Troisième point, plus structurel : une partie de l'État français a découvert qu'elle ne pouvait pas appliquer un correctif critique en moins de 48 heures sans couper le service. Ce n'est pas un problème PHP. C'est un problème d'architecture.