En bref : un WAF à la place de la mise à jour ne fonctionne pas avec PHP2Shell. Un pare-feu d'applications web (WAF), c'est-à-dire un filtre devant le site, examine les requêtes et peut bloquer des schémas d'attaque connus. Mais la faille elle-même se trouve dans l'interpréteur PHP et ne disparaît qu'avec la mise à jour et le redémarrage de tous les processus PHP. Un WAF est une couche supplémentaire judicieuse et un pont de quelques jours, pas la solution.
Pourquoi cette question est posée si souvent en ce moment
Pendant la semaine de PHP2Shell, de nombreux exploitants ont lu une nouvelle apparemment bonne : selon ses propres indications, Cloudflare a des règles de protection actives depuis le 21/10/2026 à 03 h 02 UTC, y compris pour les clients de l'offre gratuite. Celui qui est de toute façon derrière Cloudflare ou un autre WAF se demande, à juste titre, si la mise à jour est encore urgente.
La réponse honnête est oui. Cloudflare lui-même apporte une restriction : des règles fondées uniquement sur les données de la requête ne suffisent pas, c'est pourquoi le service examine en plus la réponse du serveur. Cloudflare a en outre observé des schémas d'attaque modifiés. Et la protection n'agit que pour le trafic qui passe réellement par Cloudflare. Les détails sur ce fournisseur sont décrits dans Règles de protection de Cloudflare contre PHP2Shell. Ici, il s'agit de la pesée de principe, indépendamment du fournisseur.
Ce qu'un WAF voit et ce qu'une mise à jour change
Un WAF se place devant l'application. Il voit chaque requête, la compare à des règles et la laisse passer, la bloque ou la journalise. Il ne sait pas comment PHP traite la requête en interne. Or les deux failles de PHP2Shell naissent précisément là : CVE-2026-109618 lors d'un état de mémoire insuffisante (out-of-memory) pendant que les données de la requête ne sont initialisées que partiellement, CVE-2026-109619 par un état interne qui persiste après une requête dans le même worker.
La mise à jour corrige ce code. La cause est ensuite éliminée, quelle que soit l'apparence d'une requête. Celui qui veut comprendre à quel endroit du déroulement d'une requête cela se produit trouvera les bases dans Le cycle de vie d'une requête en PHP.
WAF à la place de la mise à jour : la comparaison honnête
| Critère | Pare-feu d'applications web | Mise à jour PHP avec redémarrage |
|---|---|---|
| Qu'est-ce qui est corrigé ? | Rien, des schémas connus sont interceptés | La cause dans l'interpréteur PHP |
| Protection contre de nouvelles variantes d'attaque | Seulement si les règles sont adaptées à temps | Oui, la faille n'existe plus |
| Contournement possible ? | Oui, par exemple via l'accessibilité directe du serveur d'origine | Non, pour autant que tous les processus PHP soient redémarrés |
| Rapidité | Souvent actif immédiatement | Dépend de la version, de l'accès et de la fenêtre de maintenance |
| Effets secondaires | Fausses alertes, formulaires ou envois de fichiers perturbés | Rares ; tests de compatibilité nécessaires en cas de changement de version |
| Utilité lors de la prochaine faille | Élevée, s'il est entretenu | Aucune, chaque faille a besoin de sa propre mise à jour |
| Aide pour PHP 8.1 et antérieur ? | Comme transition | Uniquement via rétroportage ou migration |
Le tableau montre pourquoi les deux mesures vont ensemble. Le WAF est rapide et large, mais jamais complet. La mise à jour est complète, mais seulement pour une faille donnée et pas toujours possible immédiatement.
Un point est souvent négligé en pratique : un WAF modifie le comportement du site. Des règles strictes peuvent bloquer des commandes légitimes, des formulaires de contact ou des envois de fichiers sans que personne ne le remarque tout de suite. Celui qui active un WAF en pleine crise devrait donc parcourir lui-même une fois les principaux flux du site et vérifier les journaux des premiers jours pour y repérer des requêtes bloquées mais légitimes.
Comment combiner judicieusement les deux
- Immédiatement : vérifier si un WAF est présent et si les règles adaptées sont actives. Avec Cloudflare dans les offres payantes, régler selon le fournisseur le Managed Ruleset sur Block.
- Immédiatement : s'assurer que le serveur d'origine n'est joignable que via le WAF, par exemple par une autorisation du pare-feu uniquement pour ses plages d'adresses. Sinon la protection tombe dans le vide.
- Dans la prochaine fenêtre de maintenance : mettre PHP à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou installer le rétroportage confirmé de la distribution.
- Juste après : redémarrer tous les workers et processus PHP et contrôler qu'aucun ancien processus ne tourne plus. De nouveaux fichiers seuls ne suffisent pas ; plus de détails dans Après la mise à jour : redémarrer PHP-FPM et tous les workers.
- Ensuite : conserver les règles du WAF, analyser les fausses alertes et poser des exceptions ciblées au lieu de désactiver les règles en bloc.
Avec un WAF maison fondé sur ModSecurity et l'OWASP Core Rule Set, on peut obtenir un résultat comparable ; les bases sont décrites dans Utiliser ModSecurity et l'OWASP Core Rule Set. Une forme particulière est le filtrage, proposé par des auteurs spécialisés, des requêtes d'envoi de fichiers en dehors des vrais chemins d'envoi. Il est non officiel, peut casser des formulaires et ne doit entrer en exploitation qu'après test.
Ni le WAF ni la mise à jour ne suppriment un logiciel malveillant introduit auparavant. Vérifiez après le correctif si des anomalies sont apparues depuis le 17/10/2026.
Quand vous n'avez pas besoin de WAF, et quand pas de prestataire
Un WAF n'est pas obligatoire pour tous les sites. Un petit site d'entreprise chez un hébergeur qui corrige PHP rapidement et le confirme est souvent suffisamment protégé sans WAF propre, si le CMS et les extensions sont à jour. Celui qui peut aussi mettre à jour lui-même son serveur en peu de temps n'a pas besoin du WAF comme pont.
Il devient judicieux pour les boutiques, les portails et les applications avec de nombreux formulaires, pour les anciens systèmes qui ne peuvent pas être mis à jour immédiatement, et là où plusieurs sites doivent être protégés de façon centralisée. Vous n'avez besoin d'un prestataire pour cela que si la mise en place, les tests et l'entretien courant ne sont pas couverts en interne.
Comment PHP SOS aide-t-il concrètement ?
- Nous vérifions si votre WAF se trouve réellement devant tous les accès et si le serveur d'origine est joignable directement.
- Nous mettons en place des règles ou les adaptons et testons les formulaires, envois de fichiers et interfaces pour détecter des effets secondaires.
- Nous installons la mise à jour de PHP, redémarrons tous les processus et documentons l'état.
- Là où la mise à jour prend du temps, nous faisons le pont avec le WAF et le patching virtuel et une date fixe pour le vrai correctif.
Conclusion
La question « WAF ou mise à jour » est mal posée. La mise à jour ferme la faille, le WAF gagne du temps et intercepte bien d'autres choses. Celui qui ne mise que sur le WAF s'en remet à des règles que des attaquants peuvent contourner. Celui qui ne fait que corriger se retrouve sans pont à la prochaine faille.
Questions fréquentes
Un WAF suffit-il comme protection contre PHP2Shell ?
Non. Un WAF examine le trafic et peut bloquer des schémas d'attaque connus. La faille elle-même se trouve dans l'interpréteur PHP et subsiste tant que PHP n'est pas mis à jour et redémarré. Cloudflare souligne expressément que ses règles ne remplacent pas la mise à jour.
Suis-je automatiquement protégé derrière Cloudflare ?
Uniquement pour le trafic qui passe réellement par Cloudflare. Si le serveur d'origine est joignable directement depuis Internet, la protection est contournée. Pour les offres payantes, vous devriez selon Cloudflare vérifier que le Managed Ruleset est réglé sur Block.
Un WAF vaut-il encore la peine après la mise à jour ?
Souvent oui. Un WAF peut intercepter des scans de masse, des attaques connues sur des extensions et l'utilisation abusive de pages de connexion, et gagne du temps pour la prochaine faille. Mais il demande de l'entretien et des tests, sinon des fausses alertes perturbent l'exploitation.
Qu'est-ce que le patching virtuel ?
Il s'agit de protéger temporairement une vulnérabilité par des règles placées devant l'application, au lieu de modifier le code. C'est un pont jusqu'à la vraie mise à jour, pas un substitut.