Cloudflare lance un défi de sécurité PHP pour tester son WAF après php2shell
Cloudflare a annoncé un défi de recherche en sécurité PHP (en anglais) le 27 octobre 2026. L’entreprise invite les chercheurs à tester son pare-feu applicatif web (WAF) face aux vulnérabilités critiques connues sous le nom de php2shell.
Cette annonce fait suite aux correctifs PHP du 21 octobre pour CVE-2026-109618 et CVE-2026-109619, qui peuvent permettre l’exécution de code à distance sur les installations concernées. Cloudflare décrit sa réponse dans son rapport sur les protections contre php2shell (en anglais), notamment des règles qui examinent les requêtes et les réponses.
Ce que les chercheurs sont invités à tester
Cloudflare a placé une installation volontairement vulnérable de PHP 8.5.11, exécutée sous Apache 2 avec mod_php, derrière son WAF dans un environnement isolé. Les chercheurs participant à son programme HackerOne sont invités à démontrer un contournement répondant aux critères du défi.
Le règlement limite les tests aux points d’accès désignés et impose un résultat complet, vérifié, ainsi qu’un signalement privé. Les attaques contre des tiers, les analyses hors périmètre et les dénis de service sont exclus. L’annonce officielle renvoie au règlement et au statut du défi ; Cloudflare peut y mettre fin, il faut donc consulter ces sources avant de participer.
Un WAF ne répare pas PHP
Cloudflare rappelle explicitement que bloquer une réponse n’annule pas les actions déjà exécutées sur le serveur d’origine. Filtrer le trafic peut réduire l’exposition pendant le déploiement d’une mise à jour, mais ne corrige pas le moteur PHP vulnérable.
Pour les responsables de sites, la priorité reste celle décrite dans Failles de sécurité critiques dans PHP : quelles versions installer : installer une version corrigée et maintenue, redémarrer ou remplacer les processus concernés, puis vérifier le moteur qui traite les requêtes web. Contrôler uniquement PHP en ligne de commande ne renseigne pas forcément sur la version utilisée par un pool FPM, un module Apache ou un conteneur.
L’avis de sécurité PHP (en anglais) indique 8.5.12, 8.4.27, 8.3.36 et 8.2.35 comme premières versions amont corrigées pour ces failles. Utilisez une version corrigée adaptée ou un paquet maintenu par un fournisseur avec des correctifs rétroportés ; le seul numéro du paquet ne suffit pas toujours à savoir si une distribution a appliqué le correctif.
Vérifier la mise à jour et le fonctionnement du site
Après la mise à jour, examinez les journaux du serveur et du WAF, puis recherchez la cause de fichiers, processus ou erreurs inattendus. Une réponse HTTP normale ne prouve pas qu’un serveur n’a jamais été compromis.
Pour les contrôles fonctionnels habituels, le générateur de commandes cURL permet de préparer des requêtes reproductibles. Le guide d’inspection des requêtes réseau du navigateur aide à repérer les erreurs de réponse des formulaires, des connexions et des appels API. Ces vérifications servent à confirmer que l’application fonctionne après la mise à jour ; elles ne constituent ni une analyse de vulnérabilités ni une investigation d’incident.