Le 21 octobre 2026, à la demande de l'ANSSI, le ministère de l'Intérieur a désactivé en France les sites de services administratifs locaux, dont ceux des préfectures. En Belgique, aux Pays-Bas, en Finlande et en République tchèque, les autorités ont fait de même ; en Allemagne, le ministère du Numérique a coupé une partie de ses sites. L'Agence nationale de la sécurité américaine (NSA) a également lancé un avertissement ; selon Al Jazeera, elle a conseillé de mettre hors ligne les sites impossibles à mettre à jour immédiatement. Le CERT-FR recommandait lui aussi, si possible, de couper les serveurs concernés jusqu'à l'application du correctif.
En cause : deux failles dans PHP, le langage de programmation qui fait tourner la majorité des sites web du monde. Selon les chercheurs, le code vulnérable se trouvait dans PHP depuis plus de dix ans. Des chercheurs travaillant avec l'intelligence artificielle ont montré qu'il permettait de prendre le contrôle d'un serveur, même si, comme l'a ensuite expliqué la PHP Foundation, l'un des problèmes avait été repéré dès 2024.
Cette histoire ne se résume pas à un correctif d'urgence. Elle montre comment change la chasse aux points faibles des logiciels — et pourquoi cela concerne autant ceux qui défendent que ceux qui attaquent.
Ce qu'est PHP, et pourquoi cela concerne presque tout le monde
PHP est un langage pour la partie serveur des sites : ce qui se passe « en coulisses » quand vous ouvrez une page, tapez un mot de passe ou envoyez un formulaire. Des systèmes de gestion de contenu très répandus — WordPress, Drupal, Joomla — reposent dessus.
Selon W3Techs, au 22 octobre 2026, PHP est utilisé par environ 69 % des sites web dont le langage côté serveur peut être identifié. D'où le chiffre de « 70 % d'internet » repris dans les titres. Il est approximatif : il compte des sites, pas du trafic ni des données, et tous ces sites n'étaient pas exposés de la même façon.
Un simple visiteur ne voit jamais PHP. Mais si un site qu'il utilise est piraté, les conséquences peuvent le toucher aussi : fuite de données, page défigurée, lien malveillant.
Ce qui a cédé, exactement
Les failles ont reçu les identifiants CVE-2026-109618 et CVE-2026-109619, et les chercheurs les ont baptisées PHP2Shell. Toutes deux ont obtenu une note de gravité de 9,2 sur 10 sur l'échelle CVSS 4.0.
Pour simplifier, le problème se situe à deux endroits de la façon dont PHP traite une requête du navigateur :
- quand la mémoire vient à manquer pendant le traitement d'une requête, PHP laisse des « débris » sur lesquels trébuche ensuite sa routine de nettoyage ;
- un processus PHP peut réutiliser des restes de l'état d'une requête précédente.
Imaginez un serveur de restaurant qui, parfois, ne débarrasse pas la table après le client précédent : le suivant peut se servir de ce qui reste. Pris isolément, chaque oubli est mineur. Mais les chercheurs ont montré comment les enchaîner : envoyer au serveur une requête spécialement fabriquée et lui faire exécuter les commandes de son choix.
Deux points rendent cela particulièrement dangereux. D'abord, aucun mot de passe n'est nécessaire : PHP traite la requête avant que les protections du site n'entrent en jeu. Ensuite, selon Wiz, presque toutes les versions de PHP sont touchées par au moins une des failles, jusqu'à la 5.4, sortie en 2012. Les versions jusqu'à la 8.1 incluse ne sont plus officiellement maintenues : l'équipe de PHP n'a publié pour elles que des correctifs minimaux du code source, et certaines distributions Linux proposent leurs propres corrections.
Qui l'a trouvée, et comment
Selon les chercheurs de l'entreprise de sécurité Wiz, les événements se sont enchaînés ainsi :
- 19 août : découverte de la première faille ;
- 20–21 août : ils confirment qu'elle permet de prendre le contrôle de sites sous Drupal et WordPress ;
- 24 août : signalement à l'équipe de sécurité de PHP ;
- 21 septembre : PHP reconnaît le problème et commence à préparer un correctif ;
- 21 octobre : publication des versions corrigées et des détails.
Mais Wiz n'était pas la première. L'entreprise Calif, qui travaillait avec OpenAI, affirme avoir trouvé plus tôt l'une des failles avec GPT-5.6 Sol et l'avoir signalée le 11 août. Wiz dit les avoir trouvées de façon indépendante.
Une partie de l'histoire est plus ancienne. Selon la PHP Foundation, citée par The Record, l'histoire de CVE-2026-109618 remonte à 2024, lorsque PHP a fait l'objet de son premier audit de sécurité externe depuis plusieurs années : aucun moyen d'exploiter le problème n'était alors connu, et rien n'a été fait. Les développeurs n'étaient pas non plus d'accord sur la manière de le corriger sans casser la compatibilité, et le travail s'est enlisé. Les signalements d'août en ont montré toute l'ampleur et, à partir du 11 août, sa correction est devenue la priorité absolue de l'équipe sécurité de la fondation. La fondation ajoute qu'OpenAI, Wiz et Trail of Bits ont trouvé les mêmes failles de façon indépendante lors d'audits de PHP.
Wiz indique avoir utilisé tout au long du travail son propre outil, Wiz Atlas, ainsi que les modèles de langage Gemini 4 Argon de Google et GPT-5.6 Sol d'OpenAI. D'après les chercheurs, les modèles ont aidé à trouver les failles, à écrire et adapter l'exploit — le programme qui tire parti d'une vulnérabilité — à différentes versions de PHP, et à vérifier les correctifs. Ils affirment qu'un seul spécialiste a fait en une semaine ce qui aurait auparavant demandé des mois à une équipe de tout premier plan.
Il faut ici distinguer. Que l'IA ait aidé à trouver une chaîne exploitable et à écrire l'exploit est un fait établi : tous les acteurs le disent, et la vulnérabilité est bien réelle. « L'IA a trouvé la faille » est une simplification : une partie au moins du point faible avait déjà été repérée ; la nouveauté, c'est la preuve qu'on pouvait l'exploiter, et la rapidité. Quelle part revient aux modèles et quelle part aux humains, et de combien le travail a été accéléré, relève de l'estimation des entreprises elles-mêmes.
Wiz appartient à Google : les deux sociétés dont les modèles ont servi ont donc intérêt à une belle histoire. Aucune analyse indépendante de la répartition du travail n'existe encore.
Pourquoi des États ont coupé leurs sites
D'ordinaire, les failles critiques sont divulguées de manière coordonnée : d'abord le correctif, ensuite les détails. Cette fois, le plan a déraillé. Selon SecurityWeek, des détails ont fuité en ligne avant la publication prévue des correctifs.
Le 20 octobre, PHP a prévenu que le correctif sortirait le lendemain et a invité les administrateurs à se préparer. Des experts en sécurité prévoyaient des tentatives d'attaque massives dans les minutes suivant la publication. Des entreprises ont ensuite signalé des tentatives d'exploitation, y compris avant la sortie des correctifs.
Cloudflare a compté des dizaines de milliers de tentatives dans les 45 minutes suivant la divulgation, puis des millions au matin du 22 octobre. Certains attaquants ont tenté, sans succès, d'exploiter les failles pour propager Potassium, une variante du logiciel malveillant Mirai, qui sert à constituer des botnets.
Pour l'administrateur d'un site public, le choix est simple : si le serveur ne peut pas être mis à jour tout de suite, quelques heures hors ligne valent mieux qu'un risque d'intrusion. D'où les titres sur les sites « éteints ».
Le Royaume-Uni n'a pas été épargné. Le 22 octobre, une ministre a indiqué à la Chambre des lords que 32 services numériques de l'État étaient indisponibles et 4 autres partiellement, surtout par précaution. Le Centre national de cybersécurité britannique (NCSC) a envoyé des avertissements à plus de 50 000 organisations du pays.
Au 23 octobre, les sociétés de sécurité ne signalent aucune intrusion confirmée. Mais il est tôt : les conséquences réelles apparaissent généralement des semaines plus tard.
Ce n'est pas la première fois que l'IA traque des failles
En novembre 2024, l'équipe Project Zero de Google a annoncé que son agent d'IA, Big Sleep, avait trouvé une vulnérabilité inconnue dans SQLite, une base de données très répandue. Le bug a été corrigé le jour même, avant d'atteindre une version officielle. Les auteurs écrivaient alors prudemment qu'ils « pensaient » qu'il s'agissait du premier exemple public de ce genre.
En deux ans, l'échelle a changé. Alors : un bug, corrigé avant d'avoir pu nuire. Aujourd'hui : une chaîne de failles dans les fondations de la plupart des sites web, avec une attaque qui fonctionne.
Sur l'échelle de maturité, ce n'est plus une démonstration de laboratoire : l'usage de l'IA pour trouver des vulnérabilités existe et fonctionne aujourd'hui. La question ouverte est de savoir à quel point il va se répandre, et qui s'en servira en premier.
Un outil pour les deux camps
Ce qui suit relève de l'interprétation, pas des faits.
La capacité qui a aidé Wiz et Calif est aussi à la portée de ceux qui cherchent des failles pour attaquer. Les chercheurs de Wiz le disent sans détour : la complexité « pourrait ne plus constituer une barrière significative ». Beaucoup de failles dangereuses passaient inaperçues simplement parce qu'elles étaient très difficiles à trouver et à exploiter. Si l'IA abaisse cette barrière, le vieux code présent partout sur internet pourrait s'avérer moins sûr qu'on ne le pensait.
Mais les deux camps ne sont pas à égalité. Il suffit à l'attaquant de trouver un seul serveur non mis à jour. Les défenseurs, eux, doivent tous les mettre à jour. Le goulet d'étranglement se déplace donc de la découverte des failles vers leur correction : il faut écrire un correctif, le tester et l'installer sur des millions de serveurs, dont certains tournent sur des versions qui ne sont plus maintenues.
Il y a aussi une dimension humaine. Beaucoup de technologies de base d'internet, comme PHP, sont maintenues par des équipes relativement petites. Si l'IA met au jour de plus en plus de failles graves, la charge qui pèse sur ces personnes va augmenter.
Ce que l'on ne sait pas encore
- Combien de systèmes ne sont toujours pas à jour, et combien ont été compromis. Au 23 octobre, Censys estime que plus de 34 millions de services PHP (des services web, pas des serveurs physiques) restent vulnérables ; aucune compromission massive n'est confirmée à ce stade.
- Si d'autres ont trouvé ces failles avant. Le code vulnérable existait depuis plus de dix ans, et l'un des problèmes a été repéré en 2024. On ignore si quelqu'un les exploitait en secret. Amazon indique que son réseau de leurres a enregistré une tentative d'exploitation le 17 octobre, quatre jours avant la divulgation ; on ignore comment l'attaquant a obtenu les détails.
- Quelle part du travail revient à l'IA. Seuls les participants se sont exprimés.
- Combien de failles semblables attendent encore. Si l'IA a trouvé cela dans PHP, il est raisonnable de supposer que d'autres technologies anciennes recèlent des failles similaires. Mais c'est une hypothèse, pas un fait établi.
Trois scénarios plausibles
Les défenseurs prennent l'avantage. Entreprises et développeurs open source passent le vieux code au crible avec l'IA à grande échelle et corrigent les failles avant que les attaquants ne les trouvent. Condition : un accès à ces outils, et des personnes capables de publier des correctifs à temps.
Une course à armes égales. Les correctifs d'urgence comme PHP2Shell deviennent banals, et le délai entre la divulgation d'une faille et les premières attaques se réduit à quelques minutes.
La mise à jour comme goulet d'étranglement. Les failles sont trouvées vite, mais les vieux serveurs non mis à jour restent le maillon faible, et la compétence clé devient la rapidité de mise à jour.
Ces scénarios ne s'excluent pas. Le plus probable est que des parties différentes d'internet suivent des chemins différents.
Ce que cela signifie pour vous
Si vous avez un site web — sous WordPress, par exemple —, demandez à votre hébergeur si PHP a été mis à jour. Les versions corrigées sont 8.2.35, 8.3.36, 8.4.27 et 8.5.12, ou plus récentes. Si votre site tourne sous PHP 8.1 ou antérieur, il n'y aura pas de version officielle corrigée — seulement des correctifs pour ceux qui compilent PHP eux-mêmes ou ceux de certaines distributions Linux : mieux vaut prévoir le passage à une version maintenue. Les alertes officielles sont publiées par le CERT-FR en France, le Centre pour la cybersécurité Belgique (CCB), l'Office fédéral de la cybersécurité en Suisse et le Centre canadien pour la cybersécurité au Québec.
Si vous utilisez simplement internet, rien de particulier à faire. Mais c'est le bon moment pour activer les mises à jour automatiques sur votre téléphone et votre ordinateur, et pour vous méfier des courriels du type « mettez à jour votre site en urgence » : les escrocs adorent les grandes actualités. En France, le site cybermalveillance.gouv.fr aide les particuliers en cas de doute.
La leçon principale est simple : en sécurité, ce n'est pas celui qui connaît toutes les failles qui gagne, mais celui qui les corrige vite.
Questions pour la discussion
- Est-il juste de couper des sites publics pendant quelques heures pour des raisons de sécurité, si les gens ne peuvent pas accéder aux services entre-temps ?
- Qui devrait être responsable de la sécurité de technologies dont dépend tout internet, mais que maintiennent des équipes relativement petites ?
- Le rôle de l'IA change-t-il votre regard sur cette histoire : plutôt une bonne nouvelle pour les défenseurs, ou un signal d'alarme ?
Log in or Sign up to join the discussion.