L'IA a aidé à trouver la faille dans PHP, mais corriger les vieux serveurs reste un travail d'humain

Le mercredi 21 octobre, les développeurs de PHP ont publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, annoncées la veille sans détails. Elles corrigent deux vulnérabilités baptisées ensemble PHP2Shell, toutes deux notées 9,2 sur 10 sur l'échelle CVSS. Elles sont les plus dangereuses sur les serveurs Apache avec mod_php : un attaquant peut y exécuter son propre code sans s'authentifier, avec de simples requêtes HTTP, avant même que le site ait exécuté une seule ligne. Les autres façons d'exécuter PHP ne sont pas épargnées pour autant, y compris le populaire PHP-FPM. PHP fait tourner environ 69 % des sites dont le langage côté serveur peut être identifié, dont Wikipédia et les sites sous WordPress, rapporte The Verge, qui cite W3Techs. Nous avons consacré un article à cette découverte mercredi.

Le plus ancien code vulnérable remonte à PHP 5.4, sorti en 2012. Le bug sous-jacent, dans la gestion du manque de mémoire, avait été repéré dès 2024, lors de la correction de problèmes relevés par un audit externe. Mais personne n'avait montré comment l'exploiter, si bien que l'équipe de sécurité de PHP, qui manquait de bras, a sans cesse repoussé le correctif - la PHP Foundation parle d'un « échec structurel ». En août dernier, Calif et OpenAI ont signalé le bug indépendamment l'un de l'autre, suivis deux semaines plus tard par Wiz, propriété de Google.

Wiz explique avoir utilisé les modèles Gemini 4 Argon et GPT-5.6 Sol ainsi que son propre outil, Wiz Atlas. L'entreprise affirme : « Avec des modèles d'IA de pointe et les bons outils, un seul chercheur a accompli en une semaine ce qui aurait auparavant demandé des mois de travail à une équipe de classe mondiale. » On ne sait que par OpenAI quel modèle a aidé Calif. Calif cherchait des bugs dans le cadre de Patch the Planet, un programme mené par OpenAI, et c'est OpenAI qui a annoncé que la faille avait été trouvée grâce à GPT-5.6 Sol. Calif, de son côté, ne nomme pas le modèle et indique seulement avoir utilisé des modèles accessibles à tous.

L'IA accélère aussi le travail des attaquants. CJ Moses, RSSI d'Amazon, explique que par le passé, la plupart des attaques ne commençaient qu'après la publication d'un exploit fonctionnel. Selon lui, l'IA permet aujourd'hui de construire à moindre coût un exploit fonctionnel à partir du seul correctif ou de l'avis de sécurité. Les attaquants peuvent donc être plus nombreux et frapper dans les heures, voire les minutes, qui suivent la publication des détails. Matthew Prince, PDG de Cloudflare, a indiqué que Cloudflare avait observé sur son réseau des dizaines de milliers de tentatives d'exploitation dans les 45 minutes suivant la sortie du correctif, et des millions moins de 12 heures plus tard.

Certains attaquants n'ont même pas attendu le correctif. Selon la PHP Foundation, les identifiants des vulnérabilités ont fuité en ligne la veille de la publication, et Calif a mis en ligne par erreur, pendant un court moment, la vidéo d'une attaque fonctionnelle. Cloudflare a enregistré des milliers de tentatives dans les 10 heures précédant la sortie du correctif. Amazon a trouvé dans ses données une tentative encore plus ancienne, du 17 octobre, donc antérieure à la fuite. On ignore comment quelqu'un pouvait déjà connaître la faille à ce moment-là. Aucune intrusion réussie n'a toutefois été confirmée à ce jour.

Certaines institutions ont préféré ne pas attendre. Comme le rapporte CNBC, qui cite Reuters, les Pays-Bas ont mis hors ligne le portail gouvernemental Overheid.nl, le site du port de Rotterdam et même celui du NCSC, le propre centre national de cybersécurité du pays. En Finlande, Valtori, le prestataire informatique de l'État, a déconnecté d'internet les services publics en ligne de l'administration, et en France, le ministère de l'Intérieur a temporairement mis hors ligne des sites administratifs locaux. Le CERT Polska, le CERT national polonais, avait recommandé la même chose avant même la sortie du correctif : couper temporairement les services accessibles depuis internet qui tournent sous PHP, à condition que cela ne perturbe pas le fonctionnement de l'organisation. L'agence américaine CISA conseille de mettre hors ligne les systèmes qui ne peuvent pas être mis à jour immédiatement, ainsi que tout ce qui tourne sous PHP 8.1 ou une version plus ancienne.

Certains administrateurs ont déjà mis à jour de vieux systèmes avec l'aide de l'IA et le racontent sur des forums. Sur Reddit, quelqu'un écrit : « Il m'a fallu tout juste 30 minutes avec Claude pour faire passer un système LMS complexe de 5.6 à 8.5. » Une personne qui administre des centaines de sites Drupal 7 explique que sans l'IA, ces mises à jour auraient pris des mois, et que Claude Code corrige désormais les erreurs qui apparaissent après le changement de version de PHP. Une autre personne qui administre des serveurs raconte avoir passé deux heures avec un agent à examiner ses systèmes et à planifier la mise à jour. Elle lui a ensuite demandé de préparer un tableau de bord récapitulatif, puis est partie déjeuner. Sur Hacker News, quelqu'un a écrit que Claude avait transformé son blog MediaWiki en pages statiques, si bien que le blog peut tourner sans PHP en attendant que le serveur soit corrigé. Ce ne sont que les récits des auteurs eux-mêmes, et personne ne les a vérifiés.

Mais ce sont des histoires de gens qui savaient ce qu'ils faisaient et pouvaient passer à une nouvelle version sans se presser. Quiconque doit aujourd'hui sauver en urgence un serveur de production a la tâche bien plus difficile, et ces serveurs sont légion. Recorded Future cite des scans de VirusTotal : les serveurs derrière environ 1,1 million d'adresses IP révèlent leur version de PHP, et 758 000 d'entre eux, soit près de 70 %, tournent sous PHP 8.1 ou une version plus ancienne. L'équipe de PHP ne prend plus en charge ces versions et n'a pas publié pour elles de version toute prête avec le correctif. L'agence américaine CISA conseille de mettre ces serveurs hors ligne jusqu'à leur mise à jour.

Restent les correctifs des distributions Linux et des panneaux d'administration d'hébergement, mais tout le monde n'y aura pas droit. D'après une synthèse de Digital Applied, Amazon n'a aucune intention de corriger certains paquets PHP d'Amazon Linux. Ubuntu 20.04 n'a reçu le correctif que dans Ubuntu Pro, gratuit sur cinq machines au maximum. Laravel Forge conseille donc de remplacer tout serveur sous Ubuntu 20.04 ou plus ancien par un nouveau, puis d'éteindre l'ancien.

Sans paquet tout prêt, il ne reste que les correctifs du code source publiés par l'équipe de PHP pour les versions 7.4, 8.0 et 8.1. Il faut les appliquer soi-même et compiler PHP, avec les mêmes extensions qu'auparavant. Les versions plus anciennes n'ont même pas eu droit à cela. Sur Reddit, une personne dont le site tourne sous PHP 5.6 a donc demandé à Claude de porter les correctifs vers cette version. Et d'admettre aussitôt : « Est-ce que c'est utilisable ? Qui diable peut le savoir ? »

Même après la mise à jour, difficile de savoir si un serveur est sûr. Le numéro de version affiché par php -v ne tranche pas la question : dans la synthèse de Digital Applied, 21 entrées sur 76 sont des paquets qui ont reçu le correctif mais ont gardé l'ancien numéro de version. Ubuntu 24.04, par exemple, affiche toujours 8.3.6 après la mise à jour. Même l'outil de vérification des serveurs d'OpenAI prévient qu'un résultat « UNKNOWN » ne signifie pas « corrigé ». Et installer le correctif ne suffit pas. Il faut redémarrer tous les processus PHP-FPM, car ceux lancés avant la mise à jour continuent d'exécuter l'ancien code vulnérable. Sur les serveurs avec cPanel ou Plesk, chaque version de PHP installée doit être corrigée séparément.

Les contournements rapides ont un prix. Bloquer les requêtes multipart, comme le recommande notamment Sansec, empêche l'envoi de fichiers et, dans certaines boutiques, comme l'admet l'entreprise elle-même, casse aussi le panier. Supprimer la limite de mémoire (memory_limit=-1) permet de contourner le bug de gestion du manque de mémoire, mais une seule requête peut alors accaparer toute la mémoire du serveur. L'équipe de PHP prévient d'ailleurs qu'aucun réglage ne protège complètement.

L'IA a aussi fait défaut. Selon des clients de Hostinger, le chatbot de l'entreprise soutenait que PHP-FPM n'était pas vulnérable, alors que les développeurs de PHP écrivent noir sur blanc qu'il l'est. Sur Hacker News, plusieurs personnes se sont plaintes que les filtres de sécurité de Claude et de Codex interrompaient leur travail sur cette vulnérabilité.

Un clivage simple se dessine à travers ces témoignages. L'IA accélère considérablement le travail de ceux qui savent dans quel mode PHP tourne sur leur serveur, d'où viennent les paquets et quoi vérifier après une mise à jour. Ceux qui l'ignorent obtiendront quand même un plan tout prêt, mais seront incapables de juger s'il est bon.

Le propriétaire d'un site qui ne gère pas lui-même le serveur peut commencer par poser deux questions à la personne qui s'en occupe : le correctif est-il déjà installé, et quelqu'un a-t-il examiné les journaux depuis le 17 octobre, date à laquelle Amazon a enregistré la première tentative d'exploitation ? Si personne ne sait répondre, quelqu'un sur Hacker News suggère d'envisager un hébergement infogéré, où le fournisseur se charge de maintenir PHP à jour.

Glossaire : CVSS - échelle de 0 à 10 qui sert à évaluer la gravité d'une faille de sécurité. Exploit - programme ou suite de requêtes qui tire parti d'une vulnérabilité en pratique. mod_php - PHP exécuté comme module du serveur web Apache. PHP-FPM - PHP exécuté comme un pool distinct de processus auquel le serveur web transmet les requêtes. Multipart - format de requête HTTP que les navigateurs utilisent pour envoyer des formulaires contenant des fichiers.