Sécurité : une IA a trouvé une faille dans 7 sites web sur 10, ton site est-il à l'abri ?

Cette semaine, des sites du gouvernement néerlandais et du gouvernement finlandais se sont débranchés eux-mêmes. Pas de pirate dans la salle des serveurs, pas de panne : une décision prise exprès, en attendant un correctif. Le forum de GrapheneOS (une version d'Android pour les fous de vie privée), Pinboard (un service pour ranger ses favoris) et une partie du site d'OBS (le logiciel que tous les streamers utilisent pour filmer leur écran) ont fait pareil. Le CERT-EU, l'équipe qui veille sur la sécurité informatique des institutions européennes, conseillait carrément de couper ce qu'on ne pouvait pas mettre à jour tout de suite. Tout ça pour deux failles dans PHP. Et ces deux failles, ce sont des IA qui les ont trouvées.

Couper son propre site, c'est rare. C'est arrivé cette semaine un peu partout en Europe

PHP, c'est quoi, et pourquoi tout le monde a sursauté

PHP, c'est le moteur qui fabrique les pages d'une grosse partie des sites web. Quand tu ouvres le blog de ta boulangère, la boutique en ligne du garage du coin ou une page de Wikipédia, il y a de fortes chances qu'un programme PHP soit en train de fabriquer la page à la volée, juste pour toi. WordPress, Drupal et Joomla, les trois grands logiciels qui servent à faire des sites sans être développeur, tournent tous dessus. Wiz, la société de sécurité qui a révélé l'affaire le 21 octobre, estime que PHP fait tourner sept sites web sur dix dans le monde. C'est son chiffre à elle, mais tous les recensements tombent dans ces eaux-là.

Et le problème est dans PHP lui-même, pas dans un module que tu as oublié de mettre à jour. D'après l'analyse de Wiz, toutes les versions de la dernière décennie sont touchées par au moins une des deux failles, et même une page qui affiche juste « bonjour » peut suffire. Les chercheurs ont réussi à prendre le contrôle complet de serveurs sous WordPress, Drupal et Joomla, sans mot de passe et sans compte. Ils ont baptisé ça PHP2Shell : « de PHP à la ligne de commande », c'est-à-dire de la page web aux pleins pouvoirs sur la machine.

Le responsable sécurité de la fondation PHP, Volker Dusch, a dit au Wall Street Journal que c'était le problème le plus grave que PHP ait connu depuis plus de dix ans. Il l'a comparé à Heartbleed, la faille de 2014 qui avait poussé des millions de gens à changer leurs mots de passe. Ça donne le ton !

Le vestiaire qui te rend le manteau d'un autre

Imagine le vestiaire d'un théâtre. Le préposé prend les manteaux, accroche chacun à un crochet numéroté, et te donne un ticket. Normal.

Maintenant, un soir de grosse affluence, le préposé est débordé. Il vide un crochet pour faire de la place, mais il oublie de rayer le numéro dans son carnet. Le client suivant arrive avec un ticket bien choisi, le préposé regarde son carnet, et lui tend ce qui pend au crochet : le manteau d'un autre, avec ses clés et son portefeuille dans la poche.

Le ticket ne correspond pas, mais le carnet dit oui

C'est exactement ce qui se passe dans PHP. Quand un serveur manque de mémoire en plein travail, PHP libère une case de mémoire mais garde une petite note qui pointe encore dessus. La requête suivante, qui peut venir de n'importe qui sur Internet, tombe sur cette note périmée. Selon la manière dont elle s'y prend, elle peut lire ce que la visite d'avant avait laissé (le manteau d'un autre), ou glisser ses propres instructions dans la case pour que le serveur les exécute (glisser un faux ticket dans le carnet). Et pour provoquer la cohue au vestiaire, il suffit d'envoyer au serveur un envoi un peu trop gros. Bim.

Qui les a trouvées : des IA, et des humains qui savaient où chercher

C'est là que l'histoire devient vraiment intéressante. En août, deux équipes sont tombées dessus, chacune de son côté. D'abord Calif, une équipe payée pour attaquer des logiciels avant les vrais pirates, qui auditait le code de PHP avec GPT-5.6 Sol, un modèle d'OpenAI. L'audit était payé par OpenAI dans le cadre d'un programme qui s'appelle Patch the Planet (« rafistoler la planète »). Puis Wiz, qui appartient aujourd'hui à Google, avec son propre outil et deux modèles : Gemini 4 Argon de Google et, encore, GPT-5.6 Sol.

Deux mois à garder le secret, et la fuite arrive la veille

Ce qui me plaît, c'est que personne ne raconte que l'IA a tout fait toute seule. Wiz explique que les modèles ont surtout servi à transformer une découverte en attaque qui marche vraiment : adapter le piège à chaque version de PHP, comprendre pourquoi un essai échouait, recommencer. Le genre de boulot de fourmi qui prenait des mois. Selon Wiz, un seul chercheur l'a bouclé en une semaine. Et Calif, de son côté, insiste : ils ont utilisé des modèles que tout le monde peut acheter, sans outil spécial, et ce qui a compté le plus, c'est de connaître l'histoire de PHP et ses vieux bugs. Leur phrase, en français : « aucun modèle ne déterre "tous les bugs" avec de simples consignes ».

Autrement dit, l'IA ne remplace pas le chercheur, elle lui donne dix bras. Ça rejoint ce que je racontais début septembre quand OpenAI, Google et Anthropic avaient sorti leur IA qui pirate le même jour : ces outils ont été annoncés pour les défenseurs, et cette fois, ce sont bien eux qui ont tiré les premiers. OpenAI affirme qu'à sa connaissance, les failles ont été trouvées par l'IA avant de l'être par des attaquants.

Deux jours de panique quand même

Le plan était propre : deux mois de travail en secret avec l'équipe de PHP, Cloudflare, les éditeurs de systèmes Linux et les autorités américaines, puis une publication à heure fixe, le mercredi 21 octobre à 16 h, heure de Bruxelles, pour que tout le monde se mette à jour en même temps. Sauf que des détails ont fuité avant, dans une discussion sur Hacker News, le grand forum des développeurs. Résultat, PHP a avancé sa sortie, et le bureau des pirates a ouvert plus tôt que prévu.

Cloudflare, l'entreprise qui protège et accélère une énorme partie des sites du monde, a activé des règles de filtrage pour tous ses clients, gratuits compris, à 5 h 02 du matin (heure de Bruxelles), neuf heures avant la publication. Et ses équipes ont vu en direct les attaquants modifier leurs envois pour passer à travers. watchTowr, une autre société de sécurité, a confirmé des tentatives d'attaque sur les deux failles, d'après The Next Web. Pendant ce temps, Laravel, un des outils préférés des développeurs PHP, gelait les mises en ligne de ses clients le temps de tout reconstruire avec la version corrigée.

Et OpenAI, beau joueur, annonce le même jour dans son billet un milliard de dollars d'accès subventionné à ses outils de sécurité pour les organisations qui n'ont pas les moyens de s'en payer. Elle prévient aussi que ce genre de découverte va « fortement augmenter dans les prochains mois ». On est prévenus.

Concrètement, ton site est-il concerné ?

Si tu as un site WordPress, une boutique ou un blog chez un hébergeur classique (OVH, o2switch, Hostinger, Infomaniak et les autres), c'est presque toujours ton hébergeur qui installe PHP, et c'est donc à lui de faire la mise à jour. Mais ne te contente pas de le supposer : va dans ton espace client, cherche la ligne « version de PHP », et regarde le chiffre.

Cinq minutes dans ton espace client, et tu sais si tu dors tranquille

Les versions corrigées sont les 8.5.12, 8.4.27, 8.3.36 et 8.2.35, ou plus récentes. Si tu vois 8.1, 8.0, ou pire un vieux 7.quelque chose, c'est là que ça se gâte : le projet PHP ne corrige plus ces versions. Certains hébergeurs et éditeurs de Linux appliquent quand même le correctif de leur côté, donc pose-leur la question par écrit. Et s'ils ne répondent rien de clair, profite de l'occasion pour passer ton site sur une version récente : ton WordPress te le réclamait sûrement déjà depuis des mois.

Pourquoi s'embêter pour un petit site qui ne contient rien d'important ? Parce qu'un pirate qui prend le contrôle de ton serveur ne veut pas forcément tes données. Il veut ta machine : pour envoyer des milliers de mails d'arnaque en ton nom, héberger une fausse page de banque, ou servir de relais pour attaquer quelqu'un d'autre. Et c'est ton nom de domaine qui finit sur les listes noires.

Et si tu n'as pas de site ? Tu n'as rien à faire. En tant que simple visiteur, tu ne risques rien en ouvrant une page, la faille vise les serveurs, pas ton navigateur. Le seul effet que tu verras peut-être, c'est un site administratif « en maintenance » cette semaine. Maintenant, tu sais pourquoi.

Pour la petite histoire, le site sur lequel tu me lis tourne en .NET, pas en PHP. Pour une fois, vingt-cinq ans de .NET me servent de parapluie !

Si tu es développeur

Tu peux sauter cette partie si tu ne gères pas de serveur. Les deux failles portent les numéros officiels CVE-2026-109618 et CVE-2026-109619 (la plaque d'immatriculation des failles connues), et PHP leur donne 9,2 sur 10 en gravité. La fondation PHP précise que toutes les installations qui servent des pages sont touchées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le cas le plus exposé est mod_php, où une requête anonyme peut déclencher le problème avant même que ton code ne démarre. Attention à un piège classique : la version de PHP que tu vois dans ton terminal n'est pas toujours celle que ton serveur web utilise. Vérifie les deux, la seconde dans une page de diagnostic de ton hébergeur ou de ton panneau d'administration. Dans le terminal, ça donne :

php -v
php -i | grep -i "upload_progress"

Wiz conseille de surveiller trois signes d'attaque : des envois en plusieurs morceaux suivis d'erreurs de mémoire ou de rafales d'erreurs 500, des cookies PHPSESSID anormalement longs ou mal formés, et des processus PHP qui redémarrent sans raison. Les réglages de secours qui circulent (désactiver session.upload_progress, réduire post_max_size, mettre display_errors à zéro) réduisent le risque, mais PHP le dit noir sur blanc : seule la mise à jour règle le problème. Et une fois à jour, regarde si quelqu'un n'est pas déjà entré. Comme le rappelle Madelein van der Hout, analyste chez Forrester : un correctif ferme la porte, il ne fait pas sortir celui qui est déjà dans la maison.

Mon avis

Je trouve cette histoire plutôt rassurante, et ça me surprend moi-même. Une faille cachée depuis des années dans le moteur de sept sites sur dix, trouvée par des défenseurs armés d'IA, corrigée en deux mois avec tout le monde autour de la table, et des sites qui se coupent par précaution plutôt que de croiser les doigts : c'est exactement comme ça que ça devrait se passer. La fuite de la dernière minute montre juste que le secret ne tient jamais jusqu'au bout.

Ce qui m'inquiète, c'est la suite. Les pirates ont les mêmes modèles, ils lisent les mêmes correctifs, et leurs robots ne dorment pas. Il y a moins de trois semaines, je racontais une faille exploitée en moins d'un jour. Alors la question n'est plus de savoir si ça va recommencer, mais combien de petits sites WordPress oubliés, avec leur PHP 7 d'il y a cinq ans, vont servir de chair à canon d'ici Noël. Allez, va vérifier ta version, ça prend cinq minutes !

Sources

• Wiz Research, 21 octobre 2026 : PHP2Shell, la chronologie, les quatre bugs et les applications touchées
• OpenAI, 21 octobre 2026 : Patch the Planet, la coordination de la réponse aux failles de PHP
• The Next Web : PHP sort des correctifs d'urgence pour deux failles trouvées d'abord par l'IA
• CSO Online : deux failles critiques de PHP mettent le web en alerte
• Tenable : questions fréquentes sur PHP2Shell

Article écrit avec l'aide de Claude Code, relu et corrigé par moi.