Versions corrigées disponibles pour PHP 8.2 à 8.5 Ressource communautaire indépendante · faits vérifiés le 22 octobre 2026

Vérificateur PHP2Shell / php2shell waf

Règles WAF contre PHP2Shell : ce que livre chaque fournisseur, et pourquoi ce n’est pas un correctif

Plusieurs WAF ont ajouté des protections contre PHP2Shell le 21 octobre 2026 : Cloudflare (actives par défaut), AWS WAF (règles à ajouter vous-même), Fastly Next-Gen WAF (correctif virtuel à activer), Imperva (Cloud WAF par défaut, solutions sur site après mise à jour) et Tencent Cloud WAF. Un WAF ne filtre que les schémas d’attaque connus dans le trafic qui le traverse. Mettre PHP à jour reste la seule correction complète.

Rédaction de PHP2Shell.helpVérifié le Sources officielles ↓

Un WAF protège-t-il contre PHP2Shell ?

Un WAF (pare-feu applicatif web) réduit le risque, mais ne corrige pas PHP2Shell. PHP2Shell (CVE-2026-109618 et CVE-2026-109619) se trouve dans le moteur PHP, et l’annonce de PHP précise que seule une mise à jour est une solution complète. Les règles WAF bloquent les schémas d’attaque connus dans le trafic qui traverse le WAF. Les attaquants font déjà varier leurs requêtes pour les contourner, et les requêtes qui atteignent votre serveur par un autre chemin ne sont jamais inspectées.

Quels WAF ont des règles contre PHP2Shell ?

Les fournisseurs suivants ont publié des protections contre PHP2Shell. Toutes les informations du tableau proviennent de la publication de chaque fournisseur, au 22 octobre 2026 :

FournisseurCe qui a été livréFaut-il agir ?
CloudflareSept règles gérées d’urgence le 21 octobre, plus une règle côté réponse (article)Offre gratuite : non. Offres payantes : vérifier que le Managed Ruleset est en mode blocage. Voir PHP2Shell et Cloudflare
AWS WAFRecommandations dans le bulletin AWS 2026-143 : une règle de taille du corps pour la CVE-2026-109618 et une règle personnalisée pour la CVE-2026-109619 ; AWS annonce une mise à jour de son groupe de règles gérées PHPOui : ajouter les règles à votre web ACL
Fastly Next-Gen WAFUne règle modèle (correctif virtuel) couvrant les deux CVE (article)Oui : activer la règle modèle
ImpervaCloud WAF protégé d’office ; Elastic WAF 2.2.1 et WAF Gateway V14.7 / V15.5 LTS après mise à jour (article)Cloud WAF : non. Elastic WAF et WAF Gateway : appliquer les mises à jour
Tencent CloudProtection prise en charge par le WAF et le Cloud Firewall ; détection par Host Security (avis)Vérifier dans la console que la protection est active

L’avis de sécurité d’Alibaba Cloud (22 octobre 2026) demande aux clients qui utilisent le WAF ou le Cloud Firewall d’Alibaba Cloud de laisser la protection activée, en précisant que cela ne fait que réduire le risque et ne remplace pas la mise à jour ; il ne cite aucune règle précise. Au 22 octobre 2026, nous n’avons trouvé aucun avis officiel d’Akamai sur PHP2Shell.

Que recommande AWS WAF contre PHP2Shell ?

AWS liste deux mesures compensatoires dans son bulletin de sécurité 2026-143-AWS :

  • Pour la CVE-2026-109618 : la règle SizeRestrictions_BODY du Core rule set d’AWS WAF, qui bloque les corps de requête de plus de 8 Ko (8 192 octets).
  • Pour la CVE-2026-109619 : une règle personnalisée qui bloque les requêtes POST contenant PHP_SESSION_UPLOAD_PROGRESS dans le corps, accompagné de PHPSESSID dans le corps ou dans un cookie. Le bulletin fournit le JSON de la règle à copier.

AWS précise qu’aucune des deux n’est une atténuation complète et qu’il mettra à jour le groupe de règles gérées PHP d’AWS WAF. Pour mettre à jour PHP lui-même sur EC2, Lightsail ou Elastic Beanstalk, suivez le guide du correctif PHP2Shell.

Pourquoi un WAF ne suffit-il pas à lui seul ?

Pour trois raisons :

  1. Le contournement : le WAF ne voit que le trafic qui passe par lui. Si votre serveur accepte des connexions directes, un attaquant qui trouve son adresse IP évite complètement le WAF.
  2. Les variantes : Cloudflare a signalé des attaquants qui modifiaient leurs charges pour échapper à ses règles avant même la sortie du correctif. Les règles détectent les schémas connus ; de nouvelles variantes peuvent passer entre les mailles du filet jusqu’à la mise à jour des règles.
  3. La faille reste là : le PHP vulnérable est toujours sur votre serveur, de même que tout autre chemin pour l’atteindre.

Que faire en plus du WAF ?

Mettez PHP à jour vers la version corrigée de votre branche :

BranchePremière version corrigée
PHP 8.28.2.35
PHP 8.38.3.36
PHP 8.48.4.27
PHP 8.58.5.12
8.1 et antérieuresPas de nouvelle version ; correctifs officiels du code source pour 7.4, 8.0 et 8.1

Vérifiez votre version avec le vérificateur PHP2Shell et suivez le guide du correctif PHP2Shell. En attendant de pouvoir mettre à jour, combinez le WAF avec les mesures temporaires de PHP décrites dans la page contournement de la CVE-2026-109618, et recherchez les signes de compromission avec notre liste de vérification : un WAF ajouté après la fuite n’efface pas une intrusion antérieure.

Un WAF peut-il remplacer la mise à jour PHP2Shell ?

Non. Tous les fournisseurs cités ici présentent leurs règles comme une mesure compensatoire, et l’annonce de PHP précise que seule une mise à jour est une solution complète. Servez-vous du WAF pour gagner du temps, et mettez PHP à jour.

Ces règles WAF risquent-elles de casser mon site ?

C’est possible. La règle de taille proposée par AWS bloque les corps de requête de plus de 8 Ko, ce qui empêche les gros formulaires et les téléversements. Testez d’abord en mode comptage ou journalisation si votre fournisseur le permet, et surveillez les requêtes bloquées après le passage en mode blocage.

Vérifiez votre PHP face à PHP2Shell

Saisissez la version indiquée par votre site. Nous la comparons à la première version corrigée de sa branche et vous indiquons la marche à suivre.

Vérificateur PHP2Shell →

Sources

Les faits essentiels de cette page (versions corrigées, détails des CVE, paquets des distributions et alertes des agences) proviennent de sources officielles. Les travaux de recherche, articles de presse et publications de la communauté sont signalés comme tels.