La fenêtre des défenseurs

PHP2Shell : comment l’IA a aidé à mettre au jour de vieilles failles de PHP, et pourquoi des prestataires suisses ont choisi de couper.

Le mercredi où les sites ont disparu

Le mercredi 21 octobre, à 15:45, l’hébergeur bâlois cyon a retiré son hébergement web du réseau public. My.cyon, le webmail, les serveurs managés et d’agence et le Sitebuilder ont suivi. Les boîtes aux lettres continuaient de recevoir des messages. Les sites, eux, avaient tout simplement disparu.¹

La SRF a ensuite donné l’ordre de grandeur. Cyon héberge plus de 100 000 sites, pour des associations, des PME, des blogs privés et de grandes entreprises, et les avait tous mis hors ligne pour quelques heures.² Bexio, le logiciel comptable qui rythme la journée de nombreuses petites entreprises suisses, s’était déjà mis en pause à 11:08 le matin.³ Le canton de Bâle-Ville a coupé ses sites le soir même. Une partie de l’ETH Zurich a fait de même.⁴⁵

Les réactions étaient prévisibles. Pourquoi couper ? N’est-ce pas la preuve d’une mauvaise préparation ? WordPress est-il en cause ? L’IA a-t-elle cassé Internet ?

Les faits disent l’inverse. L’interruption se voyait. La compromission qu’elle a aidé à éviter ne se serait pas vue.

Une recherche assistée par l’IA a aidé à révéler des défauts graves, présents dans PHP depuis des années. Un isolement réfléchi et des correctifs bien menés ont permis de gérer une véritable urgence. Et là où la divulgation a échoué, ce sont des humains qui se sont trompés, pas la technique qui a permis de trouver les failles.

Ce qui a vraiment cédé

La faille se trouvait sous l’application.

PHP est le langage sur lequel repose une grande partie du web. Le 21 octobre, le projet PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger deux vulnérabilités critiques. Chacune est notée 9,2 sur 10 selon CVSS v4.0. Les premières rumeurs d’un 10,0 étaient fausses.⁶⁷

La première, CVE-2026-109618, est une corruption de mémoire. Si une requête atteint la limite de mémoire de PHP au pire moment, PHP peut laisser derrière lui des données à moitié initialisées et les traiter ensuite comme valides. Sous Apache avec mod_php, une requête sans authentification peut déclencher le problème avant même que le code de l’application ne s’exécute. L’exécution de code à distance a été démontrée avec les réglages par défaut, et confirmée sous PHP-FPM par des chemins applicatifs.⁶

La seconde, CVE-2026-109619, tient à un état resté en place après une erreur fatale. De la mémoire appartenant à une requête peut être réutilisée par une requête suivante traitée par le même worker. Un use-after-free et un plantage du worker ont été confirmés, et l’auteur du signalement a démontré une exécution de code contre une application réelle sous mod_php.⁶

Les deux se logent dans la gestion de la mémoire et des erreurs, là où passe presque chaque requête. La cause se situe donc sous le CMS, le thème, le plugin et la plupart du code applicatif. Cela ne veut pas dire que chaque installation était exposée de la même façon. Tout dépend du mode d’intégration, des versions et des chemins réellement empruntés par les requêtes.⁶⁸

Il fallait certes continuer à mettre à jour WordPress, les thèmes et les plugins pour leurs propres failles. Mais remplacer WordPress par un autre produit PHP n’aurait rien changé à ces défauts du moteur. La bonne réponse était de corriger et de vérifier le moteur, pas de clouer un CMS au pilori.⁶⁸

Un problème repéré dès 2024

L’histoire révélatrice commence en 2024, pas un mercredi de pannes.

En 2024, PHP a fait l’objet de son premier audit de sécurité externe depuis des années. La Sovereign Tech Agency l’a financé, Quarkslab l’a mené. En corrigeant l’un des points relevés, un développeur du cœur de PHP a repéré les premiers signes du problème de mémoire. On a imaginé une attaque, sans trouver de voie concrète.⁶

Chaque correctif envisagé avait un prix. L’un cassait la compatibilité. Un autre ouvrait de nouveaux risques de déni de service. Un troisième exigeait des modifications d’extensions tierces qui semblaient impossibles à coordonner. Une petite équipe qui décide par consensus n’a pas su trancher, et le travail s’est arrêté puis a repris pendant des mois.⁶

La PHP Foundation ne l’a pas caché. Elle a parlé d’un échec structurel, dû à son mode de décision et au manque d’ingénieurs connaissant le moteur en profondeur.⁶ La sécurité, ce n’est pas « trouver le bug, changer une ligne, livrer ». Certains défauts profonds demandent une refonte et des tests soigneux sur plusieurs versions.

Puis 2026 a changé les preuves. En mai, la Foundation a créé une Ecosystem Security Team. Le 30 juillet, la société de sécurité Calif a commencé un audit de PHP dans le cadre du programme Patch the Planet. Le 11 août, Ryan A, chercheur chez Calif, a signalé une exécution de code inconditionnelle ayant la même cause, et OpenAI a signalé la même chose de son côté. Wiz a transmis ses propres chaînes d’attaque le 24 août. OpenAI a fourni d’autres vecteurs le 18 septembre.⁶⁸

L’IA n’a pas écrit le code défectueux. La recherche assistée par l’IA a montré à quel point un défaut qui existait déjà était grave et urgent.

Ce que l’IA a apporté, et ce qu’elle n’a pas fait

L’analyse assistée par l’IA a changé trois choses. Les modèles ont aidé les chercheurs à s’orienter dans un moteur en code natif, vaste et ancien, dont la gestion des erreurs est difficile à suivre. Les idées d’attaque pouvaient être essayées, revues et testées sur de nombreuses configurations plus vite qu’avant. Et les démonstrations ont rendu le risque lisible pour les responsables des versions : un danger théorique pour la mémoire devenait un chemin observé vers l’exécution de code.⁶⁸⁹

Selon la PHP Foundation, le travail de Calif s’appuyait sur un modèle de pointe d’OpenAI. Wiz décrit de tels modèles associés à des chercheurs chevronnés et à ses propres systèmes. Les mainteneurs mentionnent aussi un scan antérieur avec Claude Mythos d’Anthropic et des outils d’OpenAI pour le tri. Ce n’était pas le miracle d’une marque. Les modèles ont prolongé des équipes spécialisées. Ils ne les ont pas remplacées.⁶⁸⁹

Ce que l’IA n’a pas fait compte tout autant. Elle n’a pas écrit le code vulnérable, vieux de plusieurs années. Elle n’a décidé ni du tri, ni du correctif, ni de la compatibilité. Selon la Foundation, chaque décision a été prise par une personne, et une personne a travaillé sur chaque correctif.⁶ Elle n’a pas préparé les paquets des distributions, ni écrit les règles de pare-feu, ni déployé quoi que ce soit chez les hébergeurs.¹⁰⁹ Et elle n’a pas prouvé qu’aucun attaquant n’était au courant avant.¹¹

La conclusion honnête n’est donc pas que l’IA rend la défense facile. L’IA a augmenté les chances que des défenseurs trouvent et prouvent un vieux risque caché. Elle réduit aussi l’effort des attaquants. Mettre des correctifs sûrs en production avant que des capacités d’attaque bon marché ne se répandent, voilà le problème de conception de la prochaine décennie.

La fenêtre des défenseurs

Un modèle performant peut produire une découverte utile en quelques heures. Un moteur très répandu demande des semaines pour être corrigé, testé, distribué et déployé. L’écart entre ces deux horloges, c’est la fenêtre des défenseurs.

Si la fenêtre se referme avant que les exploitants disposent d’un correctif praticable, même une découverte signalée de façon responsable devient une exposition urgente. Le cas PHP montre à la fois la valeur d’une alerte précoce et la fragilité de la coordination quand une démonstration ou un binaire révélateur sort trop tôt de l’embargo.⁶⁹

OpenAI a annoncé 1 milliard de dollars d’accès subventionné à un programme de modèle de sécurité pour les défenseurs en première ligne. C’est un engagement pour l’avenir. Ce n’est pas de l’argent déjà versé à la PHP Foundation ni dépensé pour cet incident.⁹

Une bonne découverte ne se mesure pas à l’absence d’urgence visible. Elle se mesure aux compromissions futures que des correctifs vérifiés permettent d’éviter. Elles sont plus difficiles à compter que des pannes, et il ne faut pas en faire un chiffre inventé.

Quatre événements, pas une fuite

La publication coordonnée était prévue le jeudi 22 octobre à 14:00 UTC. Le mardi 20 octobre, vers 15:00 UTC, les deux numéros CVE ont commencé à circuler avec une note erronée de 10,0. Aucun détail technique n’avait fuité, et l’origine de cette première fuite reste inconnue. PHP a avancé sa préannonce à 19:30 UTC et déplacé la publication au mercredi 21 octobre, 14:00 UTC.⁶

Vers 20:00 UTC le même soir, Calif a publié par erreur une vidéo montrant sa preuve de concept contre plusieurs cibles. Elle a été supprimée, mais des copies ont circulé, et selon la Foundation la vidéo a accéléré la mise au point d’autres démonstrations. Des conseils de protection transmis vers 23:00 UTC à quelques exploitants d’infrastructures critiques ont peut-être fuité aussi.⁶

Le 21 octobre à 07:41 UTC, plus de six heures avant la publication, Chainguard a mis en ligne des images de conteneurs contenant les binaires corrigés. La Foundation a critiqué ce geste : n’importe qui pouvait désormais étudier le correctif pendant que tous les autres attendaient. Le patron de Chainguard a dit avoir publié tôt délibérément, en invoquant des signalements d’exploitation active.⁶¹² Le dilemme est réel dans les deux sens. Les sources ne le tranchent pas.

Enfin, l’équipe de renseignement sur les menaces d’Amazon a relevé dans ses honeypots, dès le 17 octobre, ce qu’elle a classé comme une tentative d’exploitation, avant toute fuite publique. Rien ne dit si de telles tentatives auraient réussi contre de vrais systèmes.¹¹

Ce sont quatre événements distincts, qui appellent quatre conclusions distinctes. « Un humain a tout divulgué » n’explique aucune cause. Et aucun d’eux ne montre que l’IA a causé les failles elles-mêmes.

Trente heures en Suisse

Toutes les heures de cette section sont à l’heure d’été suisse (CEST, UTC+2), telles que les exploitants les ont publiées. L’ENISA situe la publication des versions corrigées à 13:40 UTC, soit 15:40 en Suisse. Beaucoup de prestataires se sont calés sur l’annonce de 16:00.¹⁰¹³¹⁴

C’est un registre de ce que les exploitants ont dit publiquement, pas un classement.^{11531617181920142122} Ils ont des produits, des modèles de support et des vieilles versions de PHP différents. Une coupure courte ne prouve pas une meilleure protection. Rester en ligne ne prouve pas la négligence.

Dessinées en barres, ces fenêtres ressemblent à un classement : bexio 20 h 49 min, cyon environ 12 h 15 min, MvA 6 h 09 min pour ses serveurs web PHP, Onlime environ 46 minutes.^13162014 Ce n’en est pas un. Bexio est une application métier. Cyon exploite un vaste parc d’hébergement mutualisé. MvA échelonnait ses paquets par version de PHP. Onlime avait déjà posé un géoblocage. Une barre plus courte n’est pas un prix de sécurité, une barre plus longue n’est pas une négligence.

Couper ou rester en ligne

Le journal de statut de bexio ouvre l’urgence à 11:08 et nomme la menace PHP critique. Site web, office, cockpit, salaires, API et fonctions bancaires étaient touchés. L’incident a été clos le lendemain à 07:57, la mise à jour déployée. L’entreprise a ensuite déclaré que ses propres contrôles n’avaient révélé aucun accès non autorisé. C’est la parole de l’exploitant, pas un audit indépendant.³¹⁶²³

Cyon a attendu des paquets de sécurité adaptés à sa propre infrastructure, rétroportages pour les anciennes versions de PHP compris, plutôt que de redémarrer sur la seule foi des versions sources.¹¹⁵ Son fondateur, David Burkhardt, a expliqué à la SRF que la mesure était drastique, mais le fruit d’une pesée : avec des sites piratés, des emplois seraient en jeu, des données de clients pourraient fuiter, des systèmes entiers pourraient être détruits.²

Onlime a limité l’accès web à la Suisse, au Liechtenstein et à l’Autriche à 14:50, a coupé ses serveurs web à 16:00, a appliqué les correctifs entre 16:20 et 16:45 et tout était revenu à 16:46.¹⁴²¹ MvA a coupé tous ses serveurs web à 15:35. Les versions récentes de PHP sont revenues dès 18:17, les anciennes à 21:44, ses interfaces Plesk seulement le lendemain.²⁰ L’un disposait d’une source de paquets rapide. L’autre attendait des rétroportages pour de vieilles versions. Ni l’un ni l’autre ne prouve qu’une application financière devrait revenir en 46 minutes.

D’autres sont restés en ligne. Hosttech indique que son outil Imunify360 a appliqué automatiquement des protections le 20 octobre, que les correctifs officiels ont été installés dès environ 16:00 le 21 octobre et terminés pendant la nuit, sans coupure générale. Hosttech rappelle aussi qu’une couche de sécurité supplémentaire ne remplace pas la mise à jour du moteur.¹⁷ METANET a d’abord durci les réglages de ses serveurs, puis corrigé par étapes, en attendant par endroits les paquets de CloudLinux.¹⁸¹⁹ Green a ouvert une fenêtre de maintenance de 12 heures, de 18:05 à 06:05, et confirmé les derniers correctifs à 10:16. Il prévoyait de brèves interruptions sur certains systèmes, pas une panne de 12 heures.²² Une fenêtre de maintenance n’est pas un temps d’arrêt.

Les institutions publiques ont fait face au même choix. La cellule de crise de Bâle-Ville a décidé le mercredi soir de couper les sites cantonaux. Le lendemain à 11:45, les sites corrigés revenaient, et aucun incident de sécurité n’avait été enregistré.⁴ Le site central de l’ETH Zurich et Staffnet n’étaient pas directement touchés ; des pages WordPress et d’autres pages PHP gérées par des unités ont dû être coupées et corrigées.⁵ « Aucun incident enregistré pour l’instant » est une observation datée, pas une preuve forensique.

Une tentative n’est pas une intrusion

Amazon a relevé une tentative apparente le 17 octobre, puis d’autres le 21 octobre venant de plus d’une source, dont certaines avant la divulgation large. Elle a précisé qu’on ne savait pas si ces charges auraient réussi contre de vraies cibles.¹¹

Imperva a compté, sur ses premières 24 heures, 482 342 requêtes, 122 311 sessions d’attaque, 21 998 sites visés et 103 pays.¹³ C’est une attention automatisée à grande échelle. Ce n’est pas un nombre d’intrusions, et Imperva le dit elle-même.

Cloudflare a activé une protection par défaut pour les clients de son pare-feu le 21 octobre à 03:02 UTC et a vu les attaquants modifier leurs charges pour la contourner. Son message est simple : corrigez PHP quand même.²⁴

En Suisse, l’Office fédéral de la cybersécurité a déclaré à la SRF le 22 octobre n’avoir connaissance d’aucune attaque en Suisse attribuable à ces failles, tout en avertissant que des cas non détectés ou non signalés pourraient encore apparaître.² « Aucun cas connu » ne veut pas dire « zéro compromission ».

Les autres chiffres suisses demandent le même soin. Les « plus de 100 000 sites hors ligne » de la SRF correspondent au parc de cyon, pas à un recensement des sites suisses.² Le 22 octobre à 05:37, un scanner public signalait 16 128 sites suisses sur 466 383, soit 3,5 %. Il rangeait 437 288 sites dans une seule case « corrigé ou sans PHP », qui mélange deux états très différents.²⁵ Et la part de 69,3 % de PHP selon W3Techs ne vaut que pour les sites dont il identifie le langage côté serveur. Dans les reprises, c’est devenu « 70 % d’Internet était vulnérable ».²⁶

Il n’existe pas de perte nationale honnête en francs, pas de nombre de piratages en Suisse, pas de vainqueur de la sécurité parmi des services inégaux. Ces inconnues sont un programme de recherche, pas des cases à remplir.

Pourquoi on a accusé WordPress

WordPress est si répandu qu’un problème de PHP se présente comme un site WordPress en panne. On voit l’application, pas l’interpréteur en dessous. L’appel à abandonner le CMS se comprend donc. Techniquement, il est faux. Wiz a démontré l’exploitabilité sur WordPress, Drupal et Joomla alors que le défaut se trouvait dans le moteur PHP.⁸ Une application bien tenue peut très bien tourner sur un moteur non corrigé.

La bonne question n’est pas de savoir quel CMS n’a jamais de failles. Aucun ne peut le promettre. Elle est de savoir qui répond des couches inférieures, à quelle vitesse on corrige, si les anciennes versions sont suivies, quelle protection en périphérie et quels plans de reprise existent, et comment on communique quand une dépendance lâche. WordPress sur un PHP bien géré peut présenter moins de risque qu’un système maison sur une base négligée.

Un pare-feu fait gagner du temps ; il ne remplace pas le correctif.²⁴ Et « rien n’a été annoncé, donc c’était exagéré » confond l’absence d’intrusion observée avec l’absence d’exposition.

Juger un prestataire avec équité

Une interruption se mesure en minutes, en ventes perdues, en factures retardées. Les attaques qui n’ont pas eu lieu parce qu’un système était isolé, elles, ne se mesurent guère. Ce déséquilibre pousse le jugement public à prendre le confinement pour un échec et le risque invisible pour de la compétence.

Le client qui n’a pas pu facturer pendant une journée a subi un vrai préjudice. Mais un prestataire qui aurait sciemment laissé ses clients exposés à une prise de contrôle de leurs serveurs sans authentification, juste pour éviter cette interruption, aurait pu causer bien pire. L’ENISA et ses partenaires européens ont recommandé d’isoler temporairement les services des réseaux publics là où les correctifs ne pouvaient pas être appliqués rapidement.¹⁰

Un prestataire doté d’une protection en couches crédible peut avoir raison de rester en ligne, comme l’indique hosttech. Un prestataire sans bouclier éprouvé, ou avec de vieux moteurs exposés, peut avoir raison de couper, comme cyon et bexio.¹⁰¹³¹⁷ L’échec consiste à choisir à l’aveugle, ou à se dire « protégé » sans explication que quiconque puisse vérifier.

La question n’est donc pas « pourquoi avez-vous coupé ? », mais « quelle solution plus sûre aviez-vous, et en combien de temps avez-vous vérifié le correctif ? ». Il faut demander la dernière heure d’exposition connue, les protections actives avant le correctif, la provenance des paquets, la méthode de vérification, si les anciens workers ont été redémarrés, quels clients ont été touchés et ce que les journaux ont montré ensuite. La durée de la panne est une ligne de cet audit, pas sa note finale.

Pour la prochaine crise, il faut que cela existe sous forme de procédure permanente : une carte reliant chaque application à son moteur PHP, une trace de qui a décidé l’isolement, quand et pourquoi, des canaux de rétroportage testés pour les anciennes versions, des journaux conservés d’avant la première tentative connue, et un bilan public par composant.⁶¹⁰¹⁸

Deux budgets, pas un seul

La chronologie de PHP est un cas d’une franchise rare : une infrastructure numérique publique portée par trop peu de personnes. Une faille dans un logiciel complexe n’a rien d’exceptionnel. Ce qui devrait inquiéter tous ceux qui dépendent de PHP, c’est qu’un problème de sécurité ait pu rester bloqué sur des compromis de compatibilité pendant que la valeur bâtie dessus ne cessait de croître. La Foundation demande aux entreprises, aux plateformes d’hébergement et aux organismes publics de financer son travail de sécurité à la mesure de leur dépendance.⁶

L’IA n’a pas simplement trouvé ce que les humains avaient manqué. Elle a accéléré les découvertes et révélé un décalage dans la capacité à corriger. La Foundation a publié 15 CVE depuis le 1er juillet et traité plus de 100 signalements invalides, en double ou impossibles à reproduire.⁶ C’est un vrai problème de capacité, pas une note de bas de page.

Un programme sérieux a donc deux budgets. L’un finance l’accès aux modèles et la recherche en sécurité. L’autre finance les mainteneurs, l’infrastructure de test, la coordination avec les distributions et la vérification indépendante. L’un sans l’autre ne fait que remplir une boîte de réception.

Méthode et limites

Cette Field Note s’appuie sur les sources publiques disponibles le 23 octobre 2026 vers midi, heure suisse : déclarations des mainteneurs, avis des autorités, télémétrie de fournisseurs, pages de statut et articles de presse. Elle ne scanne aucun système, ne reproduit aucune attaque, n’examine aucune intrusion et ne certifie aucun prestataire. Les déclarations des exploitants sont rapportées comme leur propre version. Fenêtres de statut, fenêtres de maintenance et temps d’arrêt des clients restent distincts.

Restent ouverts : qui a provoqué la première fuite le 20 octobre ; si les tentatives du 17 octobre ont atteint des systèmes en production ; combien de compromissions sont confirmées, s’il y en a ; quel temps d’arrêt réel les clients ont subi ; et si la publication anticipée de Chainguard a protégé plus de monde qu’elle n’en a exposé.⁶¹¹¹² Une déclaration attribuée à Marcel Salathé sur LinkedIn n’est pas citée ici, faute d’avoir pu vérifier la publication d’origine. Si des chiffres de compromission audités ou des bilans de prestataires paraissent, ils iront dans un addendum daté, pas dans une révision silencieuse.

La panne se voyait

Le premier malentendu de cette crise consiste à prendre un service volontairement coupé pour un service sans défense, et un service resté en ligne pour un service plus sûr. Le deuxième consiste à voir une divulgation assistée par l’IA et à conclure que l’IA a créé le défaut. Le troisième consiste à parler de WordPress quand le code vulnérable se trouvait dans PHP lui-même.⁶¹⁰⁸

La vérité plus difficile est aussi la plus intéressante. Des experts ont vu les signes avant-coureurs deux ans avant la crise, mais il leur manquait le chemin d’attaque et les moyens de mener à bien une correction difficile. Des défenseurs assistés par l’IA ont transformé ce risque obscur en preuve. Des ingénieurs ont conçu et livré les correctifs. Hébergeurs et autorités ont décidé qui devait rester en ligne pendant que les correctifs se diffusaient. Et des humains ont mal géré une partie de la divulgation, tandis que des attaquants sondaient peut-être déjà.⁶⁹¹¹¹²

Les machines n’ont pas sauvé un Internet impuissant, et elles n’en ont pas ruiné un qui était sûr. La découverte s’accélère, la coordination se complique, et une gestion humaine compétente vaut davantage, pas moins. La réponse n’est pas de reculer devant l’IA. Elle est de financer et de gouverner la défense assistée par l’IA assez bien pour que la prochaine fenêtre des défenseurs s’ouvre avant qu’il faille éteindre les lumières.

Une coupure responsable est un acte de protection, pas la preuve d’un échec.

Sources