PHP2Shell : pourquoi des sites ont fermé le 21 octobre — et ce que l’IA a révélé

Météo-France, préfectures : pourquoi ces sites ont-ils fermé le 21 octobre ? Parce que deux failles dans PHP pouvaient permettre, sur des systèmes vulnérables, d’exécuter du code à distance sans compte utilisateur.

On m’a demandé plusieurs fois d’expliquer ce qui s’était passé. Alors reprenons les faits : ce que permet PHP2Shell, comment les chercheurs ont mis ces failles au jour avec l’aide de l’IA, et pourquoi les compétences techniques restent indispensables.

Ce qui s’est passé le 21 octobre

Météo-France et les sites des préfectures ont suspendu leurs accès par précaution après l’alerte. Le ministère de l’Intérieur a évoqué une maintenance préventive à la suite d’une demande de l’ANSSI. Météo-France a indiqué relayer ses informations de vigilance sur ses réseaux sociaux. Déclarations rapportées avec AFP

La Ville de Paris a également annoncé la fermeture préventive de plusieurs services en ligne, le temps de vérifier et de sécuriser les systèmes concernés. Communication de la Ville de Paris

Un site fermé par précaution n’est pas un site dont le piratage est établi. Ce sont des décisions de protection face à un risque sérieux. Dire que « tout a été hacké » serait faux.

L’alerte concerne PHP2Shell : deux vulnérabilités du moteur PHP, référencées CVE-2026-109618 et CVE-2026-109619. PHP est notamment utilisé derrière WordPress, Drupal ou Joomla. Le défaut se situe dans le moteur qui exécute les applications ; il peut donc toucher un site dont le code applicatif a été correctement écrit. Recherche PHP2Shell

Concrètement, que peut faire un attaquant ?

Sur une configuration vulnérable et lorsque les conditions d’exploitation sont réunies, il peut notamment :

• Faire exécuter du code à distance sans s’authentifier, avec les droits du processus PHP qui sert le site.
• Lire des données sensibles présentes en mémoire : mots de passe, jetons de connexion ou clés d’API, selon ce qui s’y trouve.
• Utiliser les accès obtenus pour consulter des données ou modifier des fichiers accessibles à ce processus.

Cela ne lui donne pas automatiquement tous les droits sur toute l’infrastructure. L’étendue des dégâts dépend des permissions, de l’isolation et des données accessibles. Une fuite de mémoire peut aussi se produire sans avoir d’abord réussi une exécution de code. Capacités démontrées par les chercheurs

Prenons une boutique en ligne : si le processus compromis peut accéder à des fichiers de configuration ou à des identifiants de services, les conséquences peuvent dépasser la seule page affichée. C’est un exemple de risque, pas l’annonce d’un incident sur une boutique précise.

Les chercheurs ont démontré des exploitations sur WordPress, Drupal et Joomla dans leurs environnements de test. Cela explique l’urgence de corriger ; cela ne prouve pas que tous les sites utilisant ces outils ont été attaqués. Analyse de Wiz

Pourquoi PHP pouvait-il laisser passer ça ?

Lors de certaines erreurs, notamment un épuisement de mémoire, PHP pouvait mal remettre en état ses données internes. Des informations incomplètes ou liées à une requête précédente pouvaient ensuite être réutilisées à tort.

C’est ce type de problème de mémoire que les chercheurs ont transformé en scénarios d’attaque vérifiables. Le comportement dépend aussi du mode d’exécution de PHP et des chemins accessibles dans l’application. On ne peut donc pas déduire le risque exact d’un site en regardant simplement sa page d’accueil. Explications de la PHP Foundation

Comment ces failles ont-elles été découvertes ? Quel rôle a joué l’IA ?

Le 21 octobre est la date de publication des correctifs et de la divulgation coordonnée, pas le début de la recherche.

La chronologie est instructive :

• En 2024, un développeur du cœur de PHP avait déjà repéré les premiers signes du problème d’épuisement de mémoire, en travaillant sur les suites d’un audit. Le risque était envisagé, sans scénario concret d’exécution de code identifié à ce stade.
• Le 30 juillet 2026, Calif commence un audit dans le programme Patch the Planet d’OpenAI. Le 11 août, un chercheur de Calif signale une exécution de code à distance liée à cette cause.
• En août et septembre, des travaux de Wiz et d’OpenAI apportent d’autres résultats et chemins d’attaque.
• Le 21 octobre à 16 h, heure de Paris, les correctifs sont publiés. Leur sortie a été avancée d’un jour après la circulation anticipée d’informations sur les failles. Chronologie de la PHP Foundation

OpenAI explique que Calif s’est appuyé sur GPT‑5.6 Sol dans le cadre de ce programme. Wiz a mené une découverte indépendante avec ses propres chercheurs et outils d’IA. Il faut donc parler du travail de Calif, OpenAI, Wiz et des équipes PHP, avec des rôles distincts. OpenAI, Wiz

L’IA a aidé à chercher, à explorer des chemins d’exploitation et à vérifier des résultats. Des humains ont analysé les découvertes, pris les décisions et travaillé sur les correctifs.

C’est précisément ce qui rend cette histoire intéressante : l’IA peut aider à trouver des failles très graves. Encore faut-il des personnes capables de comprendre ce qu’elle trouve et de sécuriser ce qui tourne.

Et maintenant, qu’est-ce qu’il faut corriger ?

Mettre WordPress ou un module à jour ne remplace pas la mise à jour de PHP lui-même.

Les premières versions corrigées annoncées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Pour un système utilisant les paquets d’un distributeur, il faut vérifier son bulletin : certains correctifs peuvent être rétroportés. Il faut aussi redémarrer les processus concernés pour qu’ils utilisent effectivement la version corrigée. Consignes PHP2Shell, Alerte du CERT-FR

Le travail consiste à inventorier les applications, vérifier leur exposition, appliquer les correctifs adaptés, tester et surveiller la reprise. Et prévoir un retour arrière qui ne laisse pas simplement une version vulnérable exposée.

Vous pensiez que les développeurs et les architectes étaient devenus inutiles ?

On nous promet une application en quelques prompts. L’interface fonctionne. Le bouton répond. Puis une alerte arrive.

Et là, les questions changent :

— Quelle version tourne réellement en production ? — Qui peut intervenir ? — Comment vérifie-t-on le résultat ? — Que fait-on si la mise à jour casse un service ?

Si vous ne savez même pas quelles technologies votre IA a utilisées, comment allez-vous répondre ?

De notre côté, le 21 octobre, nous avons mis à jour et vérifié plusieurs dizaines d’applications sans interruption de service. Nous avions préparé une architecture qui permettait d’intervenir. C’est notre retour sur notre périmètre ; ailleurs, une fermeture temporaire pouvait être la bonne décision.

Mon expérience du développement, de l’architecture et du management d’équipes techniques prend tout son sens dans ces moments-là.

Aujourd’hui, je travaille avec des agents IA. Je dois toujours savoir quoi leur demander, quelles décisions contrôler et comment vérifier le résultat. Les compétences peuvent s’acquérir ou être apportées par une équipe. Elles doivent exister quelque part dans le projet.

Combien de sites sont encore exposés ?

Nous n’avons pas de recensement mondial fiable permettant de compter les sites encore vulnérables, et encore moins les sites effectivement compromis.

La présence massive de PHP montre l’ampleur potentielle du problème. Elle ne permet pas de transformer tous ses utilisateurs en victimes. Les versions, les configurations, les correctifs déjà appliqués et l’exposition réelle changent la situation.

Ce qui m’inquiète, c’est la multiplication d’applications mises en ligne sans inventaire, sans suivi des alertes et sans responsable de maintenance. Avec ou sans IA.

PHP2Shell ne prouve pas que les sites fermés avaient été « vibe codés ». Il montre ce qui arrive quand une technologie très répandue impose une réaction rapide. Produire davantage d’applications sans prévoir leur maintenance augmente mécaniquement le travail que quelqu’un devra assumer ensuite.

Le Far West numérique que je vois arriver

C’est là que se situe mon inquiétude personnelle : nous sommes en train de rendre la création d’applications accessible à une vitesse folle, sans nous assurer que quelqu’un saura les maintenir derrière.

Une belle interface. Une application qui répond. Et parfois, personne pour expliquer l’architecture, identifier les dépendances ou réagir à une alerte. Si nous multiplions ces projets sans multiplier les compétences pour les suivre, voilà le Far West numérique que je redoute.

PHP2Shell est un exemple sur une technologie. Imaginez maintenant ce problème de responsabilité à l’échelle de tous les composants qui font tourner nos applications. Je ne parle pas d’un nombre de sites piratés que nous ne connaissons pas. Je parle de ce que nous risquons de construire : un web rempli de projets que leurs propriétaires ne savent plus maîtriser.

L’IA permet d’aller très vite. Elle permet aussi de faire n’importe quoi très vite si personne ne comprend ni ne contrôle ses décisions.

Je dirige aujourd’hui des agents IA avec l’expérience acquise en dirigeant des équipes de développement. Cette expérience me sert à cadrer les choix, à anticiper les problèmes et à vérifier le travail livré. Elle ne devient pas inutile parce que le code s’écrit plus vite.

On peut apprendre ces compétences. On peut s’entourer. Mais croire qu’elles ont disparu avec l’arrivée de Claude ou de Codex, c’est se préparer à un réveil difficile.

Les développeurs et les architectes ne sont pas devenus inutiles. Plus nous créons avec l’IA, plus nous avons besoin de personnes capables d’en garder la maîtrise.

Vous pouvez déléguer l’écriture du code. Vous restez responsable de ce que vous mettez en production.

Sur votre dernier projet, savez-vous qui s’occupe des mises à jour ?

Pour garder ce décryptage et ses sources sous la main, vous pouvez recevoir l’article par e-mail depuis cette page.