Imaginez un peu. Près de 70 % des sites web fonctionnent avec un seul langage de programmation, et le 21 octobre, ses développeurs ont publié un correctif d’urgence pour deux failles critiques qui l’affectaient. La vulnérabilité « php2shell » (en réalité deux failles liées) est le sujet de l’actualité en matière de sécurité cette semaine. La surprise ? C’est un modèle d’IA qui a permis de la détecter.
Si vous gérez un site web, en administrez un ou payez quelqu’un pour le faire, consacrez cinq minutes à la lecture de cet article. Voici ce qui s’est passé, comment l’IA intervient dans cette affaire et ce que vous devriez concrètement faire pour y remédier.
Alors, qu’est-ce qui a réellement posé problème ?
PHP est le langage qui sous-tend une grande partie du Web. Cloudflare, citant les données de W3Techs, indique que près de 70 % des sites Web l’utilisent. WordPress fonctionne avec ce langage. Tout comme ce blog.
Ces deux failles portent les identifiants CVE-2026-109618 et CVE-2026-109619, et chacune d’entre elles obtient un score de 9,2 sur 10 selon l’échelle CVSS. Il s’agit de la norme utilisée par le secteur pour évaluer la dangerosité d’un bug, et un score de 9,2 se situe clairement dans la catégorie « à traiter en priorité absolue ».
Voici ce qui est inquiétant : ces failles se trouvent au cœur même du moteur d’exécution PHP, c’est-à-dire le moteur qui exécute le code. Cela signifie qu’un pirate n’a pas besoin de compte, et peu importe le soin avec lequel vous avez conçu votre site. Selon The Hacker News, ces failles touchent pratiquement toutes les versions de PHP depuis la version 5.4. Sur les installations utilisant le module mod_php d’Apache, une exploitation démontrée ne nécessite qu’une seule requête non authentifiée.
L’une de ces failles peut également entraîner une fuite de mémoire depuis le serveur. Cette mémoire pourrait contenir des mots de passe, des jetons, des clés API et des certificats provenant des requêtes d’autres utilisateurs. Ce n’est pas rassurant.
Quel est le rôle de l’IA dans tout cela ?
C’est la partie dont tout le monde parle. OpenAI indique que la société de sécurité Calif « a identifié une faille critique à l’aide de GPT-5.6 Sol dans le cadre de notre initiative Patch the Planet ». En d’autres termes, l’équipe de Calif a utilisé un modèle d’IA pour repérer l’une des deux failles.
Mais soyons honnêtes. Wiz Research a également découvert et signalé ces deux failles de son propre chef, et l’équipe Codex Security d’OpenAI y a également travaillé, selon The Hacker News. OpenAI affirme également que « à notre connaissance, l’IA de pointe a détecté ces vulnérabilités avant les attaquants ». C’est une affirmation audacieuse, et comme le souligne PPC Land, le récit d’OpenAI ne s’appuie sur aucune vérification externe.
L’IA a également apporté son aide dans l’autre volet du travail. Les chercheurs affirment que des modèles d’IA ont permis de transformer ces failles en exploits fonctionnels. Un chercheur aurait accompli en une semaine environ ce qui aurait autrement pris des mois à une équipe. Calif apporte toutefois une mise au point. L’entreprise fait valoir que les modèles actuels ne sont toujours pas capables de créer de manière fiable des exploits de ce type à partir d’un code ancien et obscur sans l’aide humaine.
Et le bug lui-même ? Il est ancien. Le code vulnérable était présent dans PHP depuis plus de dix ans, et Calif a retracé ses origines jusqu’à des recherches sur PHP datant de 2004.
Pourquoi la vulnérabilité php2shell a-t-elle tourné au désastre ?
La divulgation ne s’est pas déroulée comme prévu. Le 20 octobre, un message publié sur le forum Hacker News a révélé que les deux failles seraient rendues publiques le 22 octobre. PHP a donc avancé sa publication d’un jour. Le soir même, Calif a accidentellement publié une vidéo présentant une preuve de concept fonctionnelle.
Cloudflare a activé les règles de pare-feu par défaut pour ses clients à 03 h 02 UTC le 21 octobre, avant même que le correctif officiel n’existe. PHP a ensuite publié les versions corrigées dans l’après-midi. Environ 20 minutes plus tard, la société de sécurité watchTowr a signalé des tentatives d’exploitation actives visant ces deux failles. Dane Knecht, directeur technique de Cloudflare, l’a dit sans détour : « Nous constatons l’émergence des premières attaques et mettons à jour nos mesures de protection à mesure que de nouveaux vecteurs apparaissent. »
Certaines organisations n’ont pas attendu. BambooHR a mis son service hors ligne aux États-Unis, au Canada et en Irlande par mesure de précaution. Aux Pays-Bas, des services gouvernementaux tels que DigiD et MijnOverheid ont également été mis hors ligne, tout comme le centre national de cybersécurité. Toutefois, aucune source n’a encore confirmé qu’une intrusion ait réussi sur un serveur spécifique.
Bon, que faut-il faire concrètement ?
C’est là que beaucoup se trompent. Mettre à jour WordPress, Laravel ou vos plugins ne résoudra pas le problème, car les failles se trouvent dans le runtime PHP. Comme l’indique l’article de Cloudflare : « Ces failles se trouvent dans le runtime PHP ; par conséquent, la simple mise à jour du code du site web ou d’un ou plusieurs plugins ne suffit pas à corriger ces vulnérabilités. »
Les premières versions corrigées sont :
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Si vous utilisez PHP 8.1 ou une version antérieure, le projet PHP ne propose plus de mises à jour pour ces versions ; il est donc temps de passer à une version plus récente. Après la mise à jour, redémarrez Apache, PHP-FPM et tous les workers PHP en exécution de longue durée. Et si votre serveur est géré par un hébergeur, demandez-lui directement s’il a appliqué le correctif. Ne faites pas de suppositions.
Une dernière chose. Le 23 octobre, PHP a signalé une troisième faille, CVE-2026-115560, qui affecte même les versions entièrement corrigées comme la 8.5.12. Selon Cloudflare, un correctif devrait être disponible dans la prochaine version régulière de PHP. Restez donc à l’affût, car cette histoire n’est pas encore terminée.
Pourquoi ce ne sera probablement pas la dernière
Honnêtement, l’angle de l’IA est à la fois une bonne nouvelle et un avertissement. C’est une bonne nouvelle car ce sont les défenseurs qui ont découvert ces failles en premier, du moins selon OpenAI. Mais c’est aussi un avertissement, puisque les mêmes outils fonctionnent pour les attaquants. Nous avons déjà évoqué le fait que le piratage par des agents IA était devenu peu coûteux, et php2shell montre le revers de la médaille.
OpenAI indique s’attendre à ce que « les découvertes de ce type augmentent fortement dans les mois à venir ». Par ailleurs, la Fondation PHP a admis qu’un développeur principal avait repéré des signes de cette faille de mémoire lors d’un audit externe en 2024. Les travaux ont ensuite été bloqués pendant des mois. La Fondation a qualifié ce retard de « défaillance structurelle » et affirme avoir modifié sa manière de prendre les décisions en matière de sécurité.
Le goulot d’étranglement s’est donc déplacé. La détection des bogues ne cesse de s’accélérer, tandis que leur correction reste la partie la plus lente. C’est un casse-tête pour toutes les petites équipes utilisant du code obsolète, et nous parierions que de nombreuses petites entreprises de notre région correspondent à cette description. Si les grands modèles linguistiques effectuent désormais un véritable travail, la chasse aux bogues fait clairement partie de ces tâches.
La vulnérabilité php2shell constitue-t-elle donc une victoire pour l’IA ?
En quelque sorte. La vulnérabilité php2shell montre que l’IA peut aider à déterrer des bogues graves, vieux de plusieurs décennies, cachés dans le code dont dépend la majeure partie du Web. Mais elle montre également à quel point la situation peut dégénérer dès qu’un bogue de ce type est rendu public, avec des fuites d’informations, des attaques précoces et des services mis hors ligne.
Notre avis : la chasse aux bogues par l’IA est une réalité, et elle ne va faire que s’accélérer. Les gagnants seront les équipes capables de déployer des correctifs en quelques heures plutôt qu’en plusieurs semaines. Auparavant, la rapidité des correctifs était un petit plus appréciable. Aujourd’hui, c’est une mesure de sécurité élémentaire, au même titre que de fermer sa porte d’entrée à clé le soir. Voici donc une question à poser dès aujourd’hui à votre développeur ou à votre hébergeur : si une nouvelle faille de type « php2shell » venait à être révélée le mois prochain, en combien de temps pourriez-vous effectuer la mise à jour ?