PHP2Shell : l'IA a mis au jour les failles cachées de PHP. Votre SOC est-il prêt pour la suite ?

Si votre organisation exploite des sites web, PHP figure très probablement dans son infrastructure. Le 21 octobre 2026, le projet PHP a publié en urgence des correctifs pour deux failles critiques, désormais connues sous le nom de PHP2Shell. En quelques heures, des préfectures, le site des impôts ou encore Météo-France ont été mis hors ligne par précaution, le temps d'appliquer les correctifs.

Les gros titres étaient alarmants, et en partie à juste titre. Mais l'épisode PHP2Shell montre aussi ce qui a fonctionné. Les organisations qui s'en sont le mieux sorties disposaient d'un inventaire précis de leurs systèmes, ont appliqué rapidement le correctif, ont vérifié qu'il était effectivement actif et ont analysé leurs journaux. Chacune de ces compétences peut s'acquérir par la formation.

PHP2Shell : de quoi s'agit-il ?

Il s'agit de deux vulnérabilités situées au cœur même de l'interpréteur PHP, référencées CVE-2026-109618 et CVE-2026-109619 et notées 9,2 sur 10 en sévérité (CVSS v4.0) par le projet PHP, une évaluation reprise par Unit 42. Elles permettent à un attaquant d'exécuter son propre code sur un serveur web sans authentification.

La conséquence opérationnelle tient en une phrase : mettre à jour un CMS ou ses plugins ne suffit pas. La faille est dans l'interpréteur, pas dans le site. WordPress, Drupal, Joomla et Magento sont concernés parce qu'ils tournent sur PHP, pas parce qu'ils sont en cause.

Cette ampleur explique la réaction des autorités. PHP alimente environ sept sites sur dix dont le langage côté serveur est identifiable, et Palo Alto Networks a recensé plus de 22,6 millions d'instances exposées potentiellement vulnérables, dont beaucoup exécutent des versions trop anciennes pour recevoir un correctif officiel. Plusieurs chercheurs soulignent toutefois que les preuves de concept publiques exigent des conditions de déploiement spécifiques, ce qui rend une exploitation de masse moins probable qu'annoncé initialement. Le CERT-FR observe pour sa part des tentatives ciblant des déploiements spécifiques de PHP.

Une troisième vulnérabilité, CVE-2026-115560, a été divulguée le 23 octobre. PHP estime son exploitation peu probable, elle demande une combinaison précise d'options de configuration et de code applicatif, et son correctif viendra dans un cycle ultérieur. Elle ne change pas l'urgence des deux premières, mais elle figure dans l'alerte du CERT-FR et vos équipes la croiseront.

Ce qui s'est passé, et à quelle vitesse

Quatre jours seulement séparent la première tentative d'exploitation connue de la publication du correctif. La chronologie ci-dessous retrace cette séquence.

Deux précisions importantes pour le lecteur français. D'une part, le ministère de l'Intérieur a indiqué qu'il ne s'agissait pas d'une cyberattaque : la mise hors ligne était une mesure de précaution, et non la réponse à une intrusion. D'autre part, les versions corrigées officielles ne concernent que PHP 8.2 et au-delà. Les branches 5.x, 7.x, 8.0 et 8.1 ne sont plus maintenues : le projet PHP a seulement publié des correctifs sous forme de code source pour les versions 7.4, 8.0 et 8.1, sans version binaire, et certaines distributions Linux proposent des paquets rétroportés. La seule solution durable reste la migration vers une branche maintenue.

Ces failles dormaient dans le code de PHP depuis plus de dix ans. Elles ont été trouvées avec l'aide de modèles d'IA, ce qui explique en partie la brièveté du délai entre découverte et exploitation.

Pourquoi cette vague semble différente

Le premier facteur est la vitesse. L'IA aide les chercheurs à identifier plus rapidement des failles anciennes, mais elle permet aussi aux attaquants de les exploiter plus vite. Ismael Valenzuela, d'Arctic Wolf, résume ce changement : « la question n'est plus la vitesse d'arrivée d'un patch, mais la vitesse à laquelle vous repérez votre exposition et empêchez un système compromis d'en entraîner d'autres ».

La même semaine a illustré ce que peut être une attaque automatisée. Unit 42 a rapporté une intrusion contre une agence gouvernementale européenne via une application PHP vulnérable, au cours de laquelle les attaquants ont obtenu des empreintes de mots de passe et des secrets d'authentification multifacteur en moins de deux heures. Unit 42 relève de forts indices d'une attaque pilotée par un agent d'IA plutôt que par un opérateur humain, tout en précisant ne pas pouvoir confirmer que PHP2Shell était le vecteur initial.

Quel que soit le point d'entrée, l'enseignement demeure : là où un attaquant humain peut mettre plusieurs jours à progresser d'un serveur web vers le cœur du réseau, un attaquant automatisé peut y parvenir en quelques heures. Des défenses qui reposent sur la détection d'une alerte le lendemain matin sont déjà trop lentes.

Cinq actions à mener dès maintenant

Le correctif est disponible et les mesures à prendre sont connues. Les cinq actions suivantes permettent de traiter le risque immédiat et de mieux se préparer aux prochaines vulnérabilités.

1. Mettez à jour PHP lui-même, pas seulement votre site. Passez à une version corrigée, reconstruisez vos images de conteneurs, puis redémarrez serveurs web et workers PHP pour que le correctif prenne effet. Vérifiez la version en exécution, pas seulement celle qui est installée.
2. Repérez le PHP que vous ne soupçonniez pas. Appliances, panneaux d'hébergement, images cloud et produits éditeurs embarquent souvent PHP. Demandez à vos fournisseurs de confirmer leur statut de correction. Le NCSC néerlandais tient une liste non exhaustive des produits concernés, citée par le CERT-FR.
3. Isolez la couche web. Un serveur web n'a pas à joindre directement vos services d'annuaire et vos contrôleurs de domaine. Limitez strictement ses connexions, en interne comme vers l'extérieur.
4. Partez du principe que des identifiants ont pu fuiter. Si un serveur PHP est resté non corrigé après le 17 octobre, faites tourner les mots de passe de base de données, les comptes de service et les clés API accessibles, et réinscrivez tout secret d'authentification qu'il hébergeait.

5. Analysez l'historique, pas seulement l'avenir. Conservez et exploitez vos journaux afin de détecter d'éventuels indices d'intrusion antérieure : processus inattendus lancés par PHP, requêtes d'envoi de fichiers inhabituelles, plantages répétés des processus PHP. L'application du correctif ne suffit pas, à elle seule, à clore l'incident.

Les mesures de contournement publiées par le CERT-FR, notamment sur memory_limit, post_max_size et session.upload_progress.enabled, ainsi que le filtrage des requêtes HTTP multipart au niveau d'un pare-feu applicatif, peuvent réduire l'exposition le temps d'organiser la mise à jour. Ces mesures ne sont pas qualifiées par le CERT-FR, ne couvrent pas l'ensemble des vulnérabilités et ne remplacent en aucun cas le correctif.

Comment Global Knowledge peut aider vos équipes

Appliquer le correctif règle l'incident actuel, mais ne prépare pas au suivant. Les prochaines vulnérabilités suivront probablement le même schéma, et le délai entre divulgation et exploitation se compte désormais en heures. Ce qui limite l'impact, ce sont des équipes qui savent quoi rechercher à chaque étape, du serveur exposé jusqu'au comité de direction.

Les formations ci-dessous sont celles de notre catalogue, avec leur code, leur durée et le lien de leur fiche.

Les intitulés, codes et durées indiqués ci-dessus correspondent au catalogue Global Knowledge France au 29 octobre 2026.

Ces formations sont conçues et animées par des experts de leur domaine, sur sept filières métier et cinq niveaux, et la plupart préparent à une certification reconnue. Elles sont proposées à distance, en présentiel ou en session privée pour votre organisation.

Deux parcours certifiants, propres à la France

Les formations ci-dessus peuvent être suivies individuellement. Lorsqu'il s'agit de bâtir une capacité complète plutôt que de répondre à un besoin ciblé, nous proposons deux parcours certifiants de niveau avancé, inscrits au programme CyberSecAtlas.

Les deux parcours sont éligibles à une prise en charge par l'OPCO Atlas, pouvant atteindre 100 % et sans avance de frais pour les entreprises adhérentes, sous réserve des conditions de financement en vigueur. Un conseiller formation pourra vous préciser les modalités applicables à votre situation.

Se préparer aux prochaines vulnérabilités

Greg Brockman, d'OpenAI, anticipe l'apparition de nombreuses failles de ce type dans les mois à venir. Cette perspective n'appelle pas d'inquiétude excessive, mais un investissement dans les compétences des équipes chargées de votre couche web, de vos identités et de vos opérations de sécurité.

Vous ne savez pas où sont vos écarts ? Commencez par le Cyber Ready Check : vingt affirmations, quatre piliers, un score sur 60 et le niveau qui va avec. C'est un PDF à remplir, les scores se calculent tout seuls.

Pour aller plus loin, échangez avec nos experts. Nous cartographierons vos capacités web, identité et opérations de sécurité au regard des cinq étapes ci-dessus, et un conseiller formation vous proposera un parcours adapté à votre réalité.

 _Sources

• _{CERT-FR, alerte CERTFR-2026-ALE-014, publiée le 21 octobre 2026, dernière mise à jour le 27 octobre. Versions corrigées, versions non suivies, mesures de contournement, CVE-2026-115560.}
• _{actu17, 21 octobre 2026. Préfectures, impôts, Météo-France, demande de l'ANSSI, absence de cyberattaque, surnom PHP2Shell.}
• _{Unit 42, Palo Alto Networks, note de menace sur CVE-2026-109618 et CVE-2026-109619, mise à jour le 25 octobre. Sévérité, instances exposées, intrusion contre une agence gouvernementale européenne.}
• _{iTWire, PHP2Shell. Part de PHP sur le web, chronologie du 17 au 22 octobre, citations Valenzuela et Brockman.}