En bref : selon ses propres indications, Cloudflare a des règles de protection contre PHP2Shell actives depuis le 21 octobre 2026, 03:02 UTC, y compris pour les clients de l'offre gratuite. Ces règles réduisent le risque pour le trafic qui passe par Cloudflare. Elles ne s'appliquent pas si le serveur d'origine est directement accessible, et elles ne remplacent pas la mise à jour de PHP. Qui utilise Cloudflare devrait vérifier le mode des règles, la protection de l'origine et le niveau de correctif.
Le point de départ : une protection avant même le correctif
Avec PHP2Shell, Cloudflare a été exceptionnellement précoce. Selon le blog de Cloudflare, les règles de protection étaient actives plusieurs heures avant la publication officielle des mises à jour de PHP à 14h00 UTC. Cloudflare a en outre indiqué avoir observé des tentatives d'attaque contre des clients, et que les attaquants modifiaient leurs schémas pour contourner les règles.
De nombreux exploitants en ont conclu : « Nous sommes derrière Cloudflare, donc nous sommes protégés. » Ce n'est vrai qu'en partie. Cet article explique ce que les règles couvrent réellement. Un arbitrage général entre pare-feu et mise à jour est proposé dans l'article WAF ou mise à jour ?.
Ce que Cloudflare a déployé contre PHP2Shell
Selon les indications du blog de Cloudflare, il y a trois éléments :
| Offre | Protection selon Cloudflare | Ce que vous devriez faire |
|---|---|---|
| Free | nouvelles règles dans le Managed Free Ruleset, actives automatiquement | vérifier que le domaine passe par Cloudflare |
| Pro, Business, Enterprise | règles adaptées dans le Managed Ruleset | s'assurer que le ruleset est sur « Block » |
| toutes les offres | règle standard dans le nouveau pare-feu de réponses | ne rien désactiver, surveiller les événements |
Le troisième élément est nouveau. Cloudflare l'appelle « full transaction detection » : le WAF examine non seulement la requête, mais aussi la réponse du serveur. La raison, selon Cloudflare : la requête seule ne suffit pas toujours à distinguer avec certitude une attaque du trafic normal. PHP2Shell est la première utilisation de cette fonction dans les règles gérées.
Les limites des règles Cloudflare
Aussi utiles que soient les règles, elles ont des limites claires, que Cloudflare nomme en partie lui-même :
- Uniquement le trafic via Cloudflare : les règles examinent ce qui transite par Cloudflare. Si le serveur d'origine est directement accessible par son adresse IP, un attaquant peut contourner la protection.
- Pas d'annulation : selon Cloudflare, une règle côté réponse peut retenir la réponse, mais pas défaire ce qui s'est déjà produit sur le serveur.
- Schémas d'attaque changeants : Cloudflare adapte ses règles en continu, car les attaquants modifient leurs requêtes. Entre une nouvelle variante et une nouvelle règle, il peut y avoir un vide.
- Pas un substitut à la mise à jour : Cloudflare recommande expressément de mettre à jour PHP malgré le WAF. Une mise à jour du code applicatif ou des plugins ne corrige pas non plus les failles.
- Cas particulier CVE-2026-115560 : selon le complément de Cloudflare du 23 octobre, la règle ne s'applique pas si le nom de la progression d'envoi de session a été modifié dans la configuration. Plus de détails sur cet avis sous CVE-2026-115560.
Ce que disent les requêtes bloquées et ce qu'elles ne disent pas
De nombreux clients regardent leurs événements de sécurité après l'annonce et y trouvent des requêtes bloquées. Cela montre d'abord seulement que votre domaine a été examiné et que la règle s'est appliquée. Une intrusion n'est pas pour autant établie. Inversement, une liste d'événements vide n'est pas une fin d'alerte : si une attaque a visé directement le serveur d'origine ou a eu lieu avant le 21 octobre, elle n'apparaît pas du tout chez Cloudflare.
Le recoupement avec les journaux du serveur web lui-même est plus fiable. Les requêtes qui y arrivent sans provenir d'adresses Cloudflare indiquent un accès direct. Sauvegardez ces journaux à partir du 20 octobre, comme le conseille la presse spécialisée. Cloudflare souligne en outre que des restrictions sur les envois de fichiers (uploads) peuvent réduire le risque, mais ne remplacent pas la mise à jour de PHP.
La faiblesse la plus fréquente derrière Cloudflare n'est pas la règle, mais le chemin qui la contourne : un serveur d'origine qui répond directement via son adresse IP ou via un sous-domaine non protégé.
Liste de vérification pour les clients Cloudflare
Vous ou votre prestataire pouvez accomplir ces étapes à court terme :
- Vérifier l'offre et le mode des règles : pour les offres payantes, contrôler dans le tableau de bord que le Managed Ruleset est actif en mode « Block ».
- Consulter les événements de sécurité : vérifier dans les Security Events si des requêtes bloquées apparaissent. Cela montre si vos domaines ont déjà été visés.
- Parcourir les enregistrements DNS : chaque enregistrement qui pointe vers le serveur web sans passer par Cloudflare est un contournement possible. Typiques : des sous-domaines pour le staging, le FTP ou la messagerie sur le même serveur.
- Verrouiller l'origine : configurer le serveur web pour qu'il n'accepte HTTP et HTTPS que de Cloudflare, par exemple via un pare-feu avec les plages d'adresses publiées par Cloudflare ou via un tunnel. La manière de procéder en général est décrite dans l'article Pare-feu pour serveur web.
- Tester l'accès direct : vérifier depuis l'extérieur si l'origine répond sans Cloudflare.
- Mettre à jour PHP et redémarrer : les règles sont la deuxième ligne. La première est PHP à un niveau corrigé avec le redémarrage de tous les processus PHP.
Pour l'étape 5, un test inoffensif qui ne demande que les en-têtes suffit. L'adresse IP est un espace réservé pour votre serveur d'origine :
# Le serveur d'origine répond-il directement, en contournant Cloudflare ?
curl -sI --resolve www.example.de:443:203.0.113.10 https://www.example.de/
Si vous obtenez ici une réponse normale de votre site, l'origine est directement accessible et la protection Cloudflare peut être contournée.
Comment PHP SOS aide-t-il concrètement ?
- Vérification de la configuration : nous contrôlons le mode des règles, les enregistrements DNS et l'accès direct au serveur d'origine.
- Sécuriser l'origine : nous limitons le serveur web au trafic via Cloudflare, sans interrompre votre site.
- Correctif et preuve : nous mettons à jour PHP, redémarrons tous les processus et documentons l'état.
- Analyse des événements : nous examinons les requêtes bloquées et les recoupons avec les journaux du serveur.
La manière dont nous combinons règles WAF et mesures transitoires est décrite dans WAF et correctif virtuel.
Conclusion
Les règles Cloudflare contre PHP2Shell sont un véritable gain, surtout parce qu'elles sont arrivées tôt et aussi dans l'offre gratuite. Mais elles sont un bouclier devant la porte, non une serrure à la porte. Qui se trouve derrière Cloudflare devrait s'assurer de trois choses : règles en mode Block, aucun chemin contournant le proxy et PHP à un niveau corrigé.
Questions fréquentes
Suis-je protégé contre PHP2Shell avec l'offre Cloudflare gratuite ?
Selon Cloudflare, les clients Free reçoivent eux aussi automatiquement les règles de protection. Elles ne s'appliquent toutefois qu'au trafic qui passe par Cloudflare et ne remplacent pas la mise à jour de PHP sur le serveur. Si le serveur d'origine est directement accessible, la protection ne s'applique pas.
Que dois-je configurer avec les offres Cloudflare payantes ?
Cloudflare conseille aux clients des offres Pro, Business et Enterprise de vérifier que le Managed Ruleset fonctionne en mode Block. S'il est seulement en mode journalisation, les attaques sont certes enregistrées, mais pas arrêtées.
Qu'est-ce que la « full transaction detection » ?
Une nouvelle fonction du WAF de Cloudflare qui examine non seulement la requête, mais aussi la réponse du serveur. Elle permet de reconnaître si une tentative d'attaque produit un effet, et la réponse peut être retenue. Selon Cloudflare, elle n'annule pas ce qui a déjà été exécuté sur le serveur.
Cloudflare couvre-t-il aussi CVE-2026-115560 ?
Cloudflare a complété son article le 23 octobre au sujet de CVE-2026-115560. Selon Cloudflare, la règle correspondante ne s'applique pas si le nom de la progression d'envoi de session (session upload progress) a été modifié dans la configuration PHP. Indépendamment de cela, php.net recommande de définir session.upload_progress.enabled=0.