Un WAF à IA aurait-il arrêté php2shell ? Mauvaise question.
php2shell est une faille critique dans le moteur PHP lui-même, et près de la moitié des sites PHP tournent sur une version qui ne recevra aucun correctif. Les propriétaires de sites pris de panique se tournent vers les WAF à IA. Voici pourquoi c'est la mauvaise question, et ce qui vous protège vraiment du piratage.
Une nouvelle faille PHP est tombée cette semaine, et elle est redoutable. On l'appelle php2shell. Ce sont en réalité deux failles, CVE-2026-109618 et CVE-2026-109619. PHP les note toutes les deux à 9.2 sur 10. Certains chercheurs ont parlé d'un 10 plein. Source : Help Net Security | SecurityWeek
Les détails ont fuité avant que le correctif soit prêt. Dès le 21 octobre, les attaquants frappaient des sites en production à grande échelle. Source : Hadrian
Voici ce qui fait peur. La faille est dans PHP lui-même, pas dans votre code. Votre application peut être irréprochable et vous restez exposé. Source : The Hacker News
Alors une question revient sans cesse. Un WAF à IA aurait-il arrêté ça ? Je pense que c'est la mauvaise question. Laissez-moi vous montrer pourquoi.
Ce qu'est vraiment php2shell
La plupart des failles web se trouvent dans votre application. Un champ de formulaire mal conçu. Une page de connexion fragile. php2shell, c'est autre chose. Elle vit dans le moteur PHP. C'est le moteur qui fait tourner tous les sites PHP. Source : Hadrian
Les configurations les plus risquées font tourner mod_php avec Apache. Là, l'attaquant n'a besoin d'aucune authentification. La faille peut se déclencher avant même que votre code s'exécute. PHP classe ce cas comme le plus critique. Source : Hadrian
La plupart des attaques observées jusqu'ici détournent une seule fonctionnalité. Elle s'appelle session upload progress. PHP gère mal la mémoire pendant la lecture d'un envoi de fichier. Source : Hadrian
Et voici le point pénible pour les défenseurs. La requête malveillante peut sembler parfaitement normale. C'est un envoi de fichier. Pas de guillemet SQL bizarre. Pas de balise de script. Pas de ../ dans le chemin. Il n'y a rien qui fasse hurler un filtre.
On a déjà vu ce film
Tout cela a un air de déjà-vu. Cela me rappelle les débuts de l'injection SQL. Une astuce de niche est devenue grand public à toute vitesse. L'outillage est devenu bon marché. Dès 2008, un botnet scannait le web en masse à la recherche d'un seul champ vulnérable et empoisonnait chaque site qu'il trouvait. Source : Dark Reading (Asprox, 2008)
php2shell a exactement la même forme. Elle ne demande pas d'authentification. Elle est dans le moteur. Elle est triviale à détecter par scan. Alors en ce moment, tous les acteurs, bons comme mauvais, ratissent le web à la recherche de sites vulnérables. Avec autant d'applications abandonnées dans la nature, ils sont quasiment certains d'en trouver.
Mais sur un point clé, c'est pire que l'injection SQL. L'injection SQL était une faille dans votre application. Une application maintenue pouvait la corriger dans le code. php2shell est une faille dans le moteur PHP. Sur une version en fin de vie, le propriétaire n'a aucun correctif, point. L'application abandonnée n'est pas seulement non corrigée. Elle est incorrigeable.
Oui, l'IA accélère désormais les deux camps. Les attaquants génèrent automatiquement leurs scanners. Les défenseurs rédigent automatiquement des correctifs virtuels. Mais ce n'est pas un échange équitable. L'attaquant n'a besoin que d'une seule victoire sur des millions de sites. Le défenseur, lui, doit tous les réparer. Des outils plus rapides n'aident en rien un site que plus personne ne gère.
C'est la découverte de vulnérabilités qui passe à la verticale. J'ai écrit sur ce basculement quand un modèle d'IA a fait surgir des milliers de zero-days d'un coup. php2shell est l'un des premiers effets de ce phénomène, pas le dernier.
Le vrai problème, c'est le vieux PHP
PHP a publié ses correctifs le 21 octobre. Les versions saines sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Source : Help Net Security Vous corrigez et vous êtes à l'abri. Simple, non ?
Pas pour la majorité du web. Regardez ce que font réellement tourner les sites PHP aujourd'hui. Ces chiffres proviennent du tableau des versions PHP et des correctifs établi par Hadrian, à partir des données W3Techs. Source : Hadrian, tableau version PHP / correctif officiel (W3Techs, 21 oct. 2026)
Faites le total. Environ 48.5% des sites PHP tournent sur une version qui ne recevra aucun correctif officiel. Source : Hadrian, tableau version PHP / correctif officiel PHP fait tourner environ 69.3% de tous les sites dont le backend est connu. Cela représente donc près d'un tiers de tout le web. Source : W3Techs via Hadrian
Ce sont des versions en fin de vie. Les mainteneurs en amont ont cessé de les prendre en charge il y a des années. PHP a bien publié des correctifs en code source brut pour 7.4, 8.0 et 8.1, mais il faut les compiler soi-même depuis les sources. Source : Hadrian La plupart des propriétaires de sites ne le feront jamais.
C'est le cœur du problème. Une énorme part du web ne peut pas être corrigée. Alors elle cherche plutôt quelque chose à acheter. Et le marché a une réponse toute prête. C'est le WAF à IA.
Pourquoi « un WAF à IA va-t-il me sauver » est la mauvaise question
J'ai écrit un guide complet sur ce que signifie vraiment « à IA » sur un WAF. Lisez-le pour avoir le tableau complet. En résumé, voici l'idée. Un vrai WAF à IA apprend votre trafic normal et signale ce qui sort de l'ordinaire.
Cela semble parfait pour une faille dont personne n'a encore de règle. Mais réfléchissez à ce que le modèle voit. Il voit la requête. php2shell fait ses dégâts dans la mémoire de PHP, une fois la requête laissée passer. L'indice n'est pas dans les octets qui circulent. Le modèle n'a donc rien à apprendre.
Une fois qu'un exploit public existe, un WAF peut bloquer la forme connue de l'attaque. C'est réel et utile. Mais c'est une signature. C'est un correctif virtuel. Un WAF classique à base de règles fait exactement la même chose, souvent plus vite.
Le label IA n'apporte donc pas grand-chose ici. Ce pour quoi on le vend, attraper une attaque toute neuve en lisant l'intention, est précisément ce qu'il ne peut pas faire pour une faille mémoire. Savoir quels octets cassent PHP vient de la CVE. Cela ne vient pas de l'intelligence du modèle.
Ce qui vous protège vraiment du piratage
Un WAF est une ceinture de sécurité. Ce n'est pas le frein. Voici ce qui fait le vrai travail.
- Quittez les versions PHP en fin de vie. C'est le seul vrai correctif. PHP 8.2 ou plus récent reçoit les correctifs. Tout ce qui est plus ancien vit en sursis.
- Faites tourner PHP avec le moindre privilège. Utilisez php-fpm, pas mod_php. Donnez au worker son propre utilisateur à droits réduits.
- Rendez votre dossier d'envoi non exécutable. Si un shell y atterrit, il ne doit pas s'exécuter. Un fichier
.phpdéposé ne sert à rien si le serveur refuse de l'exécuter. - Désactivez session upload progress si vous ne vous en servez pas. Réglez-le dans php.ini ou dans le pool FPM, puis redémarrez les workers.
- Bloquez les requêtes
.phpparasites. Un attaquant qui entre dépose en général un shell puis l'appelle. Une règle qui renvoie un 404 sur les fichiers.phpinconnus émousse cette étape. - Gardez des sauvegardes saines. Une machine compromise reste compromise. Le vrai correctif après une intrusion, c'est la restauration à partir d'une copie saine connue. Source : Hadrian
; php.ini ou votre pool FPM, puis redémarrez les workers.
; À régler ici, pas avec ini_set() ni .user.ini.
; Cela aide, mais ce n'est pas un correctif complet à soi seul.
session.upload_progress.enabled = 0Là où un WAF gagne vraiment sa place
Je ne dis pas de vous passer du WAF. Un WAF vous achète du temps. Et cela compte énormément quand vous ne pouvez pas corriger aujourd'hui.
Prenez Nivoli Edge comme exemple honnête. Son « PHP parser guard » bloque les envois malformés en périphérie, avant que PHP les lise. Sa propre documentation cite CVE-2026-109618 et CVE-2026-109619 parmi les failles qu'il couvre. Source : Nivoli docs
Mais lisez la ligne suivante dans cette même documentation. Le guard « réduit l'exposition aux failles de PHP lui-même » et « ne remplace pas la mise à jour de PHP ». Source : Nivoli docs Voilà une formulation honnête. J'aimerais que plus d'éditeurs écrivent comme ça.
Une règle sur les .php parasites et un parser guard ralentissent un attaquant. Ils ne rendent pas sûr un moteur non corrigé. Aucun WAF ne le fait.
Ce qu'il faut retenir
Alors, un WAF à IA aurait-il arrêté php2shell ? Pour l'attaque toute neuve, non. Pour la forme connue plus tard, une signature l'arrête, et vous n'avez pas besoin d'IA pour ça.
La vraie leçon est plus ancienne et plus ennuyeuse. Corrigez ce que vous pouvez. Si vous ne pouvez pas corriger, durcissez. Moindre privilège. Envois non exécutables. Sauvegardes saines. Puis placez un WAF devant pour gagner du temps.
La boîte que vous achetez n'est pas le correctif. Ce sont les bonnes habitudes.