Un correctif sorti en urgence, un exploit déjà public : la fenêtre pour agir est courte
Le 21 octobre 2026, la communauté PHP a dû publier ses correctifs de sécurité avec un jour d'avance. La raison : une preuve de concept détaillée a fuité le 20 octobre, avant la date prévue. Deux vulnérabilités, baptisées collectivement « PHP2Shell », touchent le cœur du langage. Si vos applications Symfony tournent sur PHP, vous êtes concerné.
Cet article résume ce que l'on sait d'après The "PHP2Shell" Crisis: Inside the Global AI-Driven Cyber Emergency (DEV Community), et ce que nous recommandons de faire côté projet. Les détails techniques fins (versions exactes, conditions d'exploitation) ne sont pas dans l'extrait de l'article source : consultez l'avis officiel du PHP Foundation avant d'agir.
Ce que l'on sait des deux failles
Les deux vulnérabilités sont référencées CVE-2026-109618 et CVE-2026-109619. Elles se situent dans les routines de gestion de la mémoire et de traitement des erreurs du moteur PHP. Leur score de sévérité est de 9,2 sur 10, soit le haut de l'échelle critique.
Le point qui change tout est la nature de l'attaque : une exécution de code à distance (RCE) sans authentification. Un attaquant n'a besoin d'aucun identifiant, d'aucun compte, d'aucune session. Il envoie des requêtes à un serveur vulnérable et peut y faire tourner son propre code.
Cela explique deux éléments rapportés par la source :
- la fuite de l'exploit a forcé un calendrier de publication accéléré ;
- plusieurs plateformes d'information, services publics et sites d'entreprise auraient été mis hors ligne par précaution, le temps de se protéger.
La source avance aussi que PHP propulse 70 à 75 % du web. Retenez surtout l'ordre de grandeur : la surface exposée est énorme, et l'automatisation des attaques en profite dès qu'un exploit circule.
Pourquoi une faille dans le cœur du langage est différente
Habituellement, une faille touche une bibliothèque ou un framework : on met à jour le paquet Composer concerné et le problème disparaît. Ici, le défaut est dans l'interpréteur lui-même. Mettre à jour Symfony, Doctrine ou vos dépendances ne corrige rien : il faut changer la version de PHP qui exécute le code.
Cela a plusieurs conséquences pratiques :
- le correctif se situe au niveau de l'infrastructure (image Docker, paquet système, hébergement), pas du dépôt applicatif ;
- chaque environnement doit être traité : production, préproduction, conteneurs de CI, postes de développement qui exposent un serveur ;
- les images de base figées depuis longtemps dans vos pipelines restent vulnérables tant qu'elles ne sont pas reconstruites.
Plan d'action pour une équipe Symfony
1. Inventorier les versions de PHP en service
Commencez par savoir précisément où tourne PHP. Sur chaque serveur, php -v donne la version du CLI, mais le SAPI qui sert le trafic (PHP-FPM, FrankenPHP, Apache) peut différer. Vérifiez aussi les conteneurs en cours d'exécution, pas seulement les Dockerfiles.
2. Déployer les versions corrigées
Repérez la version corrigée de votre branche PHP dans l'annonce officielle, puis :
- mettez à jour les paquets système ou changez le tag de l'image de base ;
- reconstruisez et redéployez vos images sans réutiliser de cache de couches ;
- redémarrez les processus PHP-FPM ou FrankenPHP, car un paquet mis à jour ne suffit pas tant que l'ancien processus tourne.
Si vous ne pouvez pas patcher immédiatement, réduisez l'exposition le temps du déploiement : filtrage au niveau du reverse proxy ou du pare-feu applicatif, restriction d'accès aux environnements non critiques, voire mise en maintenance des services les plus sensibles.
3. Chercher des traces d'exploitation
L'exploit étant public avant le correctif, une compromission a pu avoir lieu avant votre mise à jour. Auditez vos journaux :
- requêtes inhabituelles, très longues ou malformées dans les logs Nginx ou Apache depuis le 20 octobre ;
- erreurs PHP anormales ou plantages de workers autour de ces requêtes ;
- fichiers récemment créés ou modifiés dans les répertoires accessibles en écriture (
var/, public/, uploads) ;
- processus ou connexions sortantes que l'application n'a aucune raison d'ouvrir.
En cas de doute, considérez la machine comme compromise : isolez-la, conservez les journaux, puis reconstruisez depuis une image saine et renouvelez les secrets (clés d'API, mots de passe de base de données, APP_SECRET).
4. Limiter les dégâts pour la prochaine fois
Une RCE réussie hérite des droits du processus PHP. Quelques mesures réduisent l'impact :
- exécuter PHP avec un utilisateur sans privilèges, avec un système de fichiers en lecture seule hors des dossiers nécessaires ;
- isoler la base de données avec un compte aux droits minimaux ;
- segmenter le réseau pour que le conteneur web ne puisse pas joindre tout le reste de l'infrastructure ;
- automatiser la reconstruction régulière des images afin que les correctifs de sécurité arrivent sans action manuelle.
Conclusion
PHP2Shell rappelle qu'une dépendance de sécurité ne se limite pas à composer.lock. Le runtime fait partie de votre surface d'attaque, et son patch doit passer par le même circuit d'urgence que n'importe quelle vulnérabilité critique. L'ordre des priorités est simple : inventorier, patcher, redémarrer, auditer les logs, puis durcir.
Nous vous conseillons de vérifier les détails sur l'avis officiel du PHP Foundation, la source citée ici étant un article de blog communautaire dont certains éléments (portée exacte, attribution à des attaquants automatisés) méritent d'être recoupés.
Ce que ça change pour vous
Une faille vient d'être découverte dans le logiciel de base qui fait fonctionner une grande partie des sites web, et des outils d'attaque circulent déjà. Concrètement, quelqu'un peut prendre le contrôle d'un site non mis à jour sans avoir besoin d'aucun mot de passe. Si votre site ou votre boutique en ligne repose sur ce logiciel, demandez dès aujourd'hui à votre prestataire de confirmer par écrit que la correction a été installée, et de vérifier qu'aucune trace d'intrusion n'apparaît depuis le 20 octobre. Une vérification rapide coûte bien moins cher qu'un site piraté ou une interruption de vente.
