La faille PHP était connue depuis deux ans. L'IA a trouvé la clé en un été.

Ce week-end, j’ai vérifié la version de PHP qui fait tourner le formulaire de mon site.

Parano ? Peut-être. Mais mercredi 21 octobre, à la demande de l’ANSSI, le ministère de l’Intérieur a coupé ses sites exposés, dont ceux des préfectures.

Ce qui s’est passé

Le 21 octobre 2026, PHP a publié des correctifs pour deux failles critiques, et le CERT-FR a publié dans la foulée l’alerte CERTFR-2026-ALE-014. Les deux failles permettent d’exécuter du code à distance sur un serveur, sans authentification. Autrement dit, quelqu’un d’extérieur peut prendre la main.

PHP est partout. C’est le langage de la plupart des sites WordPress, de beaucoup d’extranets et d’outils internes développés il y a dix ans. Selon l’ANSSI, plus de 600 000 serveurs l’exécutent sur l’internet français.

Les versions corrigées sont 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Pour toutes les branches plus anciennes, de 5.x à 8.1.x, il n’y aura pas de correctif : elles ne sont plus maintenues. Le CERT-FR recommande d’isoler les serveurs touchés, puis de migrer vers une version maintenue.

Pourquoi l’IA change la donne

Ce qui m’a frappé n’est pas la faille. C’est sa chronologie.

D’après ActuIA, le défaut à l’origine de l’une des deux failles avait été signalé dès 2024, lors d’un audit. À l’époque, personne ne savait comment l’exploiter. Il est resté deux ans dans cet état : connu, mais sans danger démontré.

Cet été, plusieurs équipes s’y sont remises. Une RCE a été signalée le 11 août. Wiz Research, qui a apporté d’autres vecteurs d’attaque fin août, dit avoir travaillé avec des modèles d’IA de Google et d’OpenAI, et affirme qu’un seul chercheur a fait en une semaine ce qu’une équipe experte aurait mis des mois à faire. C’est l’affirmation de Wiz, je la prends comme telle. Mais le sens est clair.

L’IA accélère aussi ceux qui cherchent vos failles. Le délai entre « un défaut est connu » et « une attaque est possible » se raccourcit. Une vieille version qui dormait tranquille peut devenir une porte ouverte en un été.

Le risque, c’est de ne pas savoir ce qui tourne

Sur mon propre site, le seul code qui tourne côté serveur est un formulaire en PHP. En tête du fichier, j’ai écrit un commentaire : « écrit pour PHP 7.4 et plus ». C’était un choix de compatibilité. PHP 7.4 fait partie des versions qui ne recevront aucun correctif.

La faille n’est pas dans mon code, elle est dans PHP. Ce qui compte n’est donc pas la version pour laquelle le code est écrit, c’est celle qui l’exécute. Et cette ligne dit une chose simple : même sur un petit site, on peut ne pas avoir en tête ce qui tourne réellement.

Dans une PME, c’est rarement un seul formulaire. C’est le site vitrine refait en 2019, l’extranet client du prestataire parti depuis, le petit outil de devis qu’un stagiaire a codé, le WordPress de l’événement de 2022 jamais éteint. Personne ne ment. Personne ne sait, c’est tout.

Ma position : une entreprise qui ne sait pas lister ses serveurs exposés en dix minutes n’est pas prête à brancher un agent IA sur son système d’information. Un agent qui lit vos bases et écrit dans vos outils ajoute une surface d’exposition. On ne l’ajoute pas sur un terrain qu’on ne connaît pas.

Trois gestes, cette semaine

1. Lister. Tout ce qui est accessible depuis internet : sites, extranets, formulaires, outils internes ouverts à l’extérieur. Pour chacun, qui en répond.
2. Demander. La version de PHP de chacun, à l’hébergeur ou au prestataire. Chez la plupart des hébergeurs mutualisés, elle se lit ou se change dans l’espace client en quelques clics.
3. Isoler. Ce qui tourne sur une version hors support et ne peut pas migrer tout de suite : le couper ou le placer derrière un pare-feu applicatif, en attendant la migration, comme le recommande le CERT-FR.

Ce n’est pas un chantier d’IA. C’est une cartographie. C’est la même que celle qu’on fait avant d’automatiser un process : savoir ce qui existe avant de décider quoi changer.

Moralité

Avant d’automatiser, on cartographie. Y compris ce qui tourne.