Technologie

PHP : les failles débusquées par l'IA qui ont fait tomber des sites aux quatre coins du Web

Deux failles critiques, trouvées grâce à l'IA, ont touché PHP, le langage qui fait tourner une large part du Web. Sites gouvernementaux, encyclopédie et blogues de quartier ont été touchés, selon The Verge et Engadget.

PHP : les failles débusquées par l'IA qui ont fait tomber des sites aux quatre coins du Web

Mercredi, une partie du Web a vacillé sans que la plupart des internautes comprennent pourquoi. Des sites aussi différents que 4chan, DeviantArt, Wikipédia et le blogue où le bar du coin publie des photos de chiens de clients ont connu des perturbations. Le point commun tient en trois lettres : PHP. Deux failles jugées « critiques » viennent d'être découvertes dans ce langage de programmation, et leur particularité est qu'elles ont été trouvées à l'aide de l'intelligence artificielle, selon The Verge.

Ce que l'on sait, et ce que l'on ne sait pas encore

Les informations disponibles à l'heure d'écrire ces lignes viennent essentiellement de deux médias : The Verge, qui parle de deux bogues à l'origine de « problèmes majeurs » pour plusieurs plateformes connues, et Engadget, qui rapporte que des sites gouvernementaux de l'Union européenne et du Canada ont été mis hors ligne. Engadget relaie aussi la consigne qui circule : tous les sites utilisant PHP devraient appliquer le dernier correctif de sécurité.

Ce que ces comptes rendus ne permettent pas d'établir, c'est l'ampleur exacte des dégâts. On ignore, à ce stade, combien de sites ont réellement été compromis, combien ont simplement été retirés du réseau par précaution, et si des données ont été volées. La distinction compte : un site mis hors ligne par mesure préventive n'a pas forcément été piraté. Les administrateurs gouvernementaux, en particulier, préfèrent couper un service quelques heures plutôt que de laisser une brèche ouverte.

Le nom de code qui circule dans l'adresse de l'article de The Verge, « php2shell », suggère que l'une des failles pourrait permettre à un attaquant d'obtenir un accès de type « shell », c'est-à-dire de faire exécuter ses propres commandes sur un serveur. Il s'agit toutefois d'une déduction à partir d'un intitulé : les détails techniques précis devront être confirmés par les mainteneurs du langage et par les chercheurs qui ont signalé les bogues.

Pourquoi trois lettres suffisent à paralyser autant de sites

PHP n'a rien d'une technologie de pointe, et c'est précisément ce qui rend l'épisode si révélateur. Créé au milieu des années 1990, ce langage s'exécute du côté du serveur : c'est lui qui assemble les pages avant de les envoyer au navigateur. Il est gratuit, facile à apprendre et offert par la quasi-totalité des hébergeurs, ce qui en a fait la colonne vertébrale d'une énorme proportion du Web.

L'élément le plus structurant, comme le souligne The Verge, est WordPress. Ce système de gestion de contenu est écrit en PHP, et tout site qui en dépend hérite des forces et des faiblesses du langage. Or WordPress alimente, selon les estimations courantes de l'industrie, plus d'un site sur dix dans le monde, des blogues personnels aux médias en passant par les boutiques en ligne. Quand une faille touche PHP lui-même, elle ne vise pas un logiciel en particulier : elle touche le terrain sur lequel tous ces logiciels sont bâtis.

C'est aussi ce qui explique la diversité des victimes mentionnées. Une plateforme de forums anonymes, un site de communauté artistique, une encyclopédie collaborative et un modeste blogue commercial n'ont rien en commun, sauf leur dépendance à la même brique logicielle. La panne ressemble moins à une attaque ciblée qu'à une défaillance d'infrastructure invisible, que l'on remarque seulement lorsqu'elle cède.

L'IA dans le rôle du chasseur de failles

Le détail qui retient l'attention des spécialistes est la manière dont les failles ont été découvertes. Selon The Verge, ce sont des outils d'intelligence artificielle qui ont permis de les débusquer. L'épisode illustre un basculement amorcé depuis quelques années : la recherche de vulnérabilités, longtemps affaire de spécialistes patients qui épluchaient du code ligne par ligne, s'automatise.

Cette évolution a deux visages. Du côté défensif, l'IA peut analyser d'immenses bases de code et repérer des erreurs qu'un œil humain manquerait, ce qui accélère les correctifs. Du côté offensif, les mêmes outils sont à la portée de ceux qui cherchent à exploiter les failles plutôt qu'à les signaler. La course est donc double : plus les chercheurs de bonne foi trouvent vite, plus les acteurs malveillants disposent, eux aussi, d'une méthode pour trouver ou reproduire.

Pour un langage aussi ancien et aussi répandu que PHP, dont la base de code s'est accumulée sur près de trente ans, le défi est particulier. Des portions de code anciennes, rarement relues, peuvent receler des défauts que personne n'avait cherché à examiner à cette échelle. Les outils d'IA ont, en quelque sorte, ouvert des tiroirs que l'on croyait fermés.

Le vrai goulot : appliquer le correctif

Publier un correctif n'est que la première étape. Engadget l'indique sans détour : tous les sites qui utilisent PHP doivent installer le dernier correctif de sécurité. Or c'est là que le bât blesse, comme dans presque toutes les crises de ce genre.

Une partie des sites tournent sur des hébergements mutualisés où la version de PHP est choisie par le fournisseur, et non par le propriétaire du site. D'autres reposent sur des versions anciennes que l'on n'ose pas mettre à jour de peur de casser une extension ou un thème. D'autres encore sont tout simplement abandonnés, mais toujours en ligne, et ne seront jamais corrigés. Cet écart entre la date de publication d'un correctif et son déploiement réel est la fenêtre dans laquelle les attaquants opèrent.

Le cas des organismes publics est instructif. Les sites gouvernementaux de l'Union européenne et du Canada mentionnés par Engadget ont été retirés du réseau le temps de la manœuvre. C'est une réaction prudente, mais elle rappelle qu'une faille dans une brique commune oblige même des administrations bien équipées à choisir entre disponibilité et sécurité. Les sites personnels et les petites entreprises, qui n'ont ni équipe dédiée ni procédure d'urgence, sont nettement plus vulnérables.

Ce que les propriétaires de sites devraient faire

Les conseils de base, qui valent pour n'importe quel site fonctionnant sous PHP ou WordPress, sont connus mais trop rarement appliqués :

  • vérifier auprès de l'hébergeur quelle version de PHP est utilisée et si le correctif de sécurité a été installé ;
  • mettre à jour WordPress, ses thèmes et ses extensions, car une couche à jour sur un langage vulnérable ne suffit pas, mais une couche périmée aggrave le risque ;
  • activer les mises à jour automatiques lorsque c'est possible ;
  • conserver des sauvegardes récentes, stockées hors du serveur, afin de pouvoir restaurer un site en cas de compromission ;
  • surveiller les journaux d'accès et les fichiers modifiés, pour repérer d'éventuels signes d'intrusion dans les jours suivants.

Pour les utilisateurs ordinaires, la marge de manœuvre est mince : on ne peut pas corriger le site d'un autre. La prudence consiste à se méfier des messages d'hameçonnage qui surfent souvent sur ce genre d'actualité, et à changer ses mots de passe si un service que l'on utilise confirme une atteinte à ses données.

Une leçon sur la fragilité de l'infrastructure commune

Au-delà de l'urgence, l'épisode rappelle une réalité inconfortable : une part considérable de l'économie numérique repose sur des composantes libres, maintenues par des communautés de bénévoles et de petites équipes, et déployées par des millions d'acteurs qui ne les ont jamais examinées. Cette architecture a rendu le Web accessible à tous, mais elle concentre le risque. Un seul défaut, au bon endroit, se répercute partout.

L'arrivée de l'IA dans la recherche de vulnérabilités ne fait qu'accentuer la tension. Elle accélère les découvertes, donc les correctifs, mais elle comprime aussi le temps dont disposent les administrateurs pour réagir. La question n'est plus de savoir si d'autres failles de cette envergure seront trouvées dans des briques logicielles anciennes, mais à quelle vitesse l'écosystème saura les absorber.

Les prochains jours diront si l'incident s'est limité à des interruptions temporaires ou s'il a ouvert la porte à des intrusions durables. Les mainteneurs de PHP, les hébergeurs et les équipes de sécurité des organismes touchés devraient préciser le bilan. En attendant, la consigne reste la plus simple et la plus difficile à suivre : mettre à jour, et vite.