PHP2Shell : l’IA l’a découvert, l’IA l’arrête.

Ramy HoussainiVice-président, conseil en déploiement avancé

Debrup GhoshChef de produit principal | F5

Muhammad AbidDirecteur senior du marketing produit, F5

Toutes les équipes de sécurité connaissent ce moment : une faille critique est publiée, et la première question n’est plus : « Que devons-nous corriger ? » mais : « Qu’est-ce qui nous protège en attendant ? »

Avec PHP2Shell, les équipes de défense n’ont même pas bénéficié de leur avance habituelle. Des informations ont fuité le 20 octobre, avant même qu’un correctif ne soit disponible, et des attaquants auraient déjà exploité la faille avant la publication des correctifs le lendemain.

Le 21 octobre, le projet PHP a publié en urgence des correctifs pour CVE-2026-109618 et CVE-2026-109619, deux failles d’exécution de code à distance sans authentification qui touchent la quasi-totalité des serveurs PHP sur Internet. Un attaquant n’a pas besoin de se connecter. Il lui suffit de pouvoir atteindre le serveur et d’envoyer une requête spécialement conçue de téléversement de fichier qui provoque un épuisement de la mémoire de PHP en cours de traitement. PHP se fie alors aux données corrompues laissées en mémoire, et l’attaquant peut l’amener à exécuter son propre code, avant même que l’application n’exécute une seule ligne. La requête doit donc être bloquée avant même d’atteindre PHP.

Ces failles existent depuis des décennies. Ce qui est nouveau, c’est la manière dont elles ont pu être exploitées. Comme l’expliquent les chercheurs de Wiz qui les ont révélées, « Les modèles d’IA de pointe ont considérablement abaissé cet obstacle, transformant une faille ancienne en un exploit. »

Lorsque l’IA réduit le délai entre une ancienne faille et un exploit opérationnel, la protection doit être en place avant même la publication de l’avis de sécurité.

Pour les clients F5 utilisant F5 WAF en mode blocage, que ce soit sur F5 BIG-IP, F5 NGINX ou F5 Distributed Cloud, cette protection était déjà en place.

Le WAF optimisé par l’IA le bloquait déjà

Les ingénieurs en sécurité de F5 ont repris l’exploit de démonstration publié, en ont créé plusieurs variantes et les ont lancées contre une application protégée par F5 WAF for Distributed Cloud avec le WAF basé sur l’IA activé. Ils n’ont ajouté aucune règle spécifique à PHP2Shell et n’ont apporté aucune modification à la configuration.

Les variantes utilisaient différents encodages, emplacements de charge utile, méthodes HTTP et techniques de contournement courantes. Le WAF optimisé par l’IA les a bloquées en mode blocage. Il s’agit d’une véritable mesure de protection, et non d’une entrée de journal que quelqu’un consulte le lendemain matin. Pendant ce temps, une requête normale adressée à la même application a été autorisée sans encombre.

Voici à quoi ressemblait l’une de ces requêtes bloquées dans F5 WAF for Distributed Cloud :

Lors des tests de F5, les signatures existantes de F5 WAF for Distributed Cloud contre les injections par sérialisation d’objets PHP ont détecté une requête de type PHP2Shell dans le champ de progression du téléversement de session de PHP, avant même qu’une signature propre à PHP2Shell n’existe.

Bloquer en toute confiance, sans crainte

Détecter une attaque et avoir suffisamment confiance pour la bloquer sont deux choses différentes. De nombreuses équipes de sécurité conservent les nouvelles détections en mode alerte uniquement, car bloquer une requête légitime revient à refuser l’accès à un véritable client. Pour ces équipes, une attaque comme PHP2Shell est consignée dans les journaux, mais pas bloquée.

Le WAF optimisé par l’IA change la donne. Il repose sur un réseau neuronal, un type de modèle d’apprentissage automatique entraîné à partir de données d’attaques réelles issues des opérations de sécurité mondiales de F5. Comme il apprend à reconnaître les schémas d’attaque au lieu d’attendre la création d’une nouvelle règle, il peut identifier un nouvel exploit dont le comportement ressemble à celui d’attaques déjà observées. Pour chaque requête suspecte, il évalue les éléments qui semblent malveillants à la lumière de ce qu’il a appris, détermine si le contenu est réellement dangereux et fournit un verdict unique sur le niveau de risque, sur lequel le WAF agit immédiatement.

Le WAF basé sur l’IA a attribué à une requête d’attaque PHP2Shell un score de 95 sur 100, correspondant à un risque critique, en s’appuyant sur les enseignements tirés d’attaques antérieures. Bonne pratique : configurez-le en fonction du résultat souhaité.

Pour PHP2Shell, le verdict était de 95 sur 100. Les requêtes malveillantes ont été bloquées sur-le-champ, tandis que le trafic légitime a continué à circuler.

C’est ce changement qui compte pour l’entreprise. Lorsque vous utilisez le mode blocage, vous pouvez bloquer les menaces en toute confiance. Vous n’avez pas à craindre que la sécurité ralentisse votre activité ni que votre service d’assistance soit submergé par les réclamations de clients bloqués à tort.

Autre bonne nouvelle : auparavant, les équipes hésitaient à activer les règles de détection les plus susceptibles de se déclencher à tort, par crainte des faux positifs. Cette recommandation n’est désormais plus d’actualité. F5 préconise d’activer la détection à tous les niveaux de précision (élevé, moyen et faible) et de bloquer les requêtes que le WAF optimisé par l’IA considère comme présentant un risque élevé ou moyen. Le modèle prend alors en compte tous les signaux disponibles et se charge de filtrer les fausses alertes.

Les correctifs virtuels réduisent la fenêtre d’exposition

PHP2Shell n’est pas un cas isolé. Selon le rapport M-Trends 2026 de Mandiant, les attaquants exploitent désormais les vulnérabilités en moyenne environ sept jours avant qu’un correctif ne soit disponible. À l’autre extrémité de cet intervalle, le rapport 2024 de Verizon sur les violations de données révèle qu’il faut environ 55 jours aux organisations pour corriger ne serait-ce que la moitié de leurs vulnérabilités critiques dont on sait qu’elles font l’objet d’attaques. En combinant ces deux constats, la plupart des organisations restent exposées pendant des semaines.

Le correctif virtuel permet de combler cette lacune. Il ne s’agit pas d’une fonctionnalité propre à un produit, mais d’un concept : tout mécanisme qui neutralise les effets d’une vulnérabilité sans mettre à jour le logiciel vulnérable lui-même. Une signature de WAF qui bloque une exploitation constitue un correctif virtuel. Il en va de même pour une règle de politique de sécurité conçue pour une faille précise ou pour un modèle capable de reconnaître l’attaque comme telle. Dans tous les cas, le trafic malveillant est bloqué sur le chemin des données et n’atteint jamais le code vulnérable, tandis que les développeurs corrigent le problème à la source en suivant le processus habituel de gestion des changements.

C’est ce qui s’est passé avec PHP2Shell. Le WAF de F5 sur F5 Distributed Cloud, F5 BIG-IP, ainsi que sur F5 NGINX assurait déjà une protection grâce aux signatures existantes, avant même la création d’une règle propre à PHP2Shell.

Parce que nous croyons au principe de défense en profondeur, les chercheurs en sécurité de F5 ne se sont pas arrêtés là. L’équipe a publié des signatures dédiées aux vulnérabilités CVE-2026-109618 et CVE-2026-109619 pour ces produits, renforçant encore davantage la protection dont bénéficiaient déjà les clients. Les détails des signatures et leur disponibilité par produit figurent dans l’avis de sécurité F5.

Le prochain est déjà écrit

PHP2Shell donne un aperçu de ce qui nous attend : des failles vieilles de plus de dix ans transformées en exploits opérationnels à la vitesse de l’IA, le suivant arrivant encore plus vite. Les systèmes de défense qui attendent la publication d’une nouvelle règle après la divulgation continueront de perdre la première manche. Voici comment se préparer à cette faille et à la suivante :

1. Appliquez les correctifs PHP lorsque vos contraintes opérationnelles le permettent. La plupart des équipes ne peuvent pas mettre à niveau tous leurs serveurs du jour au lendemain, et c’est précisément pour combler ce délai que les correctifs virtuels ont été conçus.
2. Assurez-vous que votre WAF bloque les attaques au lieu de se contenter de les surveiller. Un WAF en mode surveillance enregistre une attaque, mais ne l’arrête pas. Vérifiez que les politiques protégeant les applications PHP sont en mode blocage.
3. Activez le WAF basé sur l’IA et fournissez-lui tous les signaux disponibles. Activez la détection à tous les niveaux de précision, bloquez les requêtes présentant un risque élevé ou moyen et vérifiez que les signatures dédiées à PHP2Shell sont actives.
4. Appliquez les signatures dédiées à PHP2Shell dès leur publication, et suivez leur disponibilité pour vos produits dans l’avis de sécurité de F5.
5. Recherchez des signes de tentatives d’exploitation. Examinez le trafic récent afin de détecter des requêtes multipart inhabituelles suivies d’erreurs de limite de mémoire PHP ou de réponses HTTP 500 répétées. Recherchez également des cookies de réponse PHPSESSID anormalement volumineux et des redémarrages inexpliqués des processus de travail PHP.
6. Réduisez la surface d’attaque. Renforcez les limites de taille des requêtes et des téléversements, et désactivez les points de terminaison de téléversement dont vos applications PHP n’ont pas besoin.

Vous ne pouvez pas décider quand la prochaine vulnérabilité sera rendue publique. En revanche, vous pouvez faire en sorte d’être prêt lorsqu’elle le sera.

En savoir plus sur l’évaluation des risques optimisée par l’IA et le WAF optimisé par l’IA.

L’avis de sécurité de F5 fournit des informations fiables et à jour sur l’impact sur les produits, les identifiants de signature, les mesures d’atténuation et la disponibilité prochaine des correctifs.

À propos des auteurs

Ramy HoussainiVice-président, conseil en déploiement avancé

Autres articles de Ramy Houssaini

Debrup GhoshChef de produit principal | F5

Autres articles de Debrup Ghosh

Muhammad AbidDirecteur senior du marketing produit, F5

Muhammad Abid est directeur principal du marketing produit pour la sécurité des applications et le WAAP chez F5. Fort de plus de 20 ans d’expérience dans le développement d’activités liées aux réseaux et à la cybersécurité chez Netskope, Cisco, Juniper et Fortinet, Muhammad supervise le portefeuille WAAP unifié de F5, qui couvre le WAF, la sécurité des API, la défense contre les bots et la cryptographie post-quantique.

Autres articles de Muhammad Abid