Des milliers de sites mis hors ligne après la découverte de failles critiques dans PHP

Créé au début des années 1990, PHP fait fonctionner environ 70 % des sites web dans le monde. Il ne sert pas seulement à afficher une page : il interroge une base de données, vérifie si un utilisateur est connecté, personnalise un contenu ou actualise une information.

Cette place explique l’ampleur de l’alerte. Une faille dans ce langage peut concerner des sites très différents lorsqu’ils utilisent PHP directement ou par l’intermédiaire d’une plateforme comme WordPress, Drupal ou PrestaShop. Les vulnérabilités identifiées pouvaient permettre de modifier un site, d’extraire des données ou de prendre le contrôle du serveur sans authentification classique.

Le correctif ne suffit cependant pas à sécuriser tout un service. Les systèmes en ligne dépendent souvent d’interfaces tierces : si l’une d’elles utilise encore une version vulnérable de PHP, un site mis à jour peut rester exposé. La mise à jour du langage ne sécurise donc pas automatiquement l’ensemble du site.

Les vulnérabilités ont été découvertes en août à l’aide de modèles d’intelligence artificielle utilisés par Wiz Research et d’autres équipes. Une autre société, Calif, les a identifiées dans le cadre d’un audit du code PHP financé par OpenAI. Les informations ont été gardées secrètes pendant la préparation d’un correctif.

OpenAI a présenté l’affaire comme l’une des vulnérabilités les plus marquantes de ces dernières années et comme le signe d’une nouvelle capacité de l’IA à repérer des défauts de sécurité avec un impact à l’échelle d’Internet. La divulgation a ensuite déclenché la mise hors ligne préventive de milliers de sites.

Le délai entre la publication des détails et leur utilisation possible a renforcé l’urgence. Steve Kerrison, maître de conférences en cybersécurité à l’université James Cook, a averti que des informations rendues publiques pouvaient être rapidement transformées en outil d’attaque. La découverte par l’IA a donc accéléré à la fois l’identification du défaut et la nécessité de corriger les systèmes avant que les techniques d’exploitation ne circulent davantage.

La publication des vulnérabilités a été suivie d’une forte hausse des tentatives d’exploitation. Cloudflare a fait état de millions de tentatives, tandis que plusieurs entreprises et autorités ont appelé à installer immédiatement la mise à jour. Des alertes ont été émises à Singapour, à Hong Kong, en Allemagne et dans d’autres pays.

Les premières évaluations ne décrivaient toutefois pas une situation uniforme. Des chercheurs ont indiqué ne pas observer d’exploitation active et généralisée des techniques disponibles. Amazon Threat Intelligence a néanmoins signalé une tentative avant même la divulgation officielle, sans pouvoir établir comment l’acteur avait obtenu les informations. D’autres éléments publiés ensuite évoquaient des premiers signaux d’exploitation effective, tandis que le centre néerlandais de cybersécurité indiquait encore ne pas disposer de signal d’un usage réussi.

La différence entre tentatives, exploitation possible et compromission avérée reste essentielle. Couper un site empêche son exposition pendant l’installation du correctif, mais ne signifie pas qu’il a déjà été attaqué. L’existence de millions de requêtes malveillantes montre toutefois que la période de correction s’est déroulée sous pression.

Vingt-quatre heures après la publication du correctif, plusieurs sites de préfectures françaises, le portail des impôts et le site Ameli restaient inaccessibles. Des services locaux, notamment ceux de la mairie de Toulouse, de Tisséo et de la ville de Limoges, ont également été temporairement coupés. Au Royaume-Uni, 32 services gouvernementaux étaient hors service jeudi, principalement par précaution. Des sites belges, néerlandais, hongrois et suisses ont connu des interruptions comparables.

Les grandes administrations et les entreprises disposant d’équipes informatiques importantes pouvaient appliquer plus rapidement la mise à jour. Le risque se prolongeait davantage pour les petites entreprises, les associations, les blogs et les sites gérés par des particuliers, parfois sans visibilité immédiate sur la version de PHP utilisée. Ces sites peuvent rester vulnérables pendant des jours, des semaines ou des mois.

La correction d’un serveur ne règle pas automatiquement les dépendances extérieures. Des interfaces tierces encore vulnérables peuvent maintenir un risque après la remise en ligne. Un service rétabli n’est donc pas nécessairement sécurisé sur l’ensemble de sa chaîne technique.