En bref : la sécurité de Symfony après PHP2Shell, c'est : corriger PHP, redémarrer tous les processus, workers Messenger compris, puis contrôler secrets, cache et profiler. La faille se trouve dans PHP, pas dans Symfony ; une mise à jour de Symfony seule ne la comble pas.
Pourquoi PHP2Shell concerne chaque projet Symfony
Symfony est la base de nombreuses applications d'entreprise, API et portails, et se trouve en outre dans des systèmes comme Shopware 6 et Contao. Les failles PHP CVE-2026-109618 et CVE-2026-109619 permettent, selon l'équipe PHP, d'exécuter du code malveillant sans authentification. Que l'application soit proprement programmée n'y change rien.
L'équipe PHP classe le risque comme le plus élevé avec mod_php, mais PHP-FPM, php-cgi, FrankenPHP et LiteSpeed sont également concernés. Les projets Symfony exploités via Symfony Runtime avec FrankenPHP ou d'autres serveurs en fonctionnement permanent exigent, après la mise à jour, un redémarrage complet ou une nouvelle image.
Sécurité Symfony : vérifier la version de PHP et les processus
php bin/console about affiche la version de Symfony, l'environnement, le mode debug et la version de PHP en ligne de commande. Les requêtes web passent toutefois par PHP-FPM ou un serveur d'applications, et il peut s'agir d'une autre version. Vérifiez les deux voies ou faites-les confirmer par l'exploitant.
Les versions corrigées en amont sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ; les backports des distributions portent souvent des numéros plus anciens. Les versions de PHP prises en charge par votre version de Symfony se vérifient dans la configuration requise de la documentation sur symfony.com.
# Afficher l'environnement, le mode debug et la version de PHP
php bin/console about
# Faire terminer les workers Messenger après le message actuel
php bin/console messenger:stop-workers
# Failles connues dans les dépendances
composer audit
Si plusieurs instances tournent derrière un répartiteur de charge ou dans des conteneurs, chacune doit être corrigée et redémarrée. Une instance oubliée continue de servir une partie des requêtes avec l'ancien PHP.
Les workers Messenger, les commandes cron et autres processus d'arrière-plan chargent PHP une seule fois au démarrage. Tant qu'ils ne sont pas redémarrés, ils fonctionnent avec l'ancien PHP en mémoire. Un gestionnaire de processus doit les relancer après l'arrêt.
Où les applications Symfony sont vulnérables
| Emplacement | Contenu | Point de contrôle |
|---|---|---|
.env, .env.local, .env.local.php |
Variables d'environnement, souvent base de données et clés API | non accessible dans le webroot, renouveler les valeurs en cas de soupçon |
config/secrets/prod/ |
secrets chiffrés | la clé de déchiffrement privée n'a pas sa place dans le dépôt |
public/ |
Racine web avec index.php |
fichiers PHP supplémentaires |
var/cache/prod/ |
conteneur généré et templates en PHP | supprimer et régénérer en cas de soupçon |
var/log/ |
Journaux | sauvegarder |
config/packages/security.yaml |
Pare-feu, rôles, règles d'accès | modifications inattendues |
Le cache est une cachette sous-estimée. Symfony y génère des fichiers PHP qui sont chargés à chaque requête. Une modification de ces fichiers ne se remarque pas dans le dépôt, car le cache n'est pas versionné.
En production, APP_ENV=prod et APP_DEBUG=0 s'imposent, et le WebProfilerBundle ne doit pas y être actif. Un profiler accessible publiquement sous /_profiler dévoile la configuration et les données de requêtes.
Espaces d'administration, bundles et dépendances
Selon leur structure, les projets Symfony ont leurs propres espaces d'administration, souvent avec des bundles comme EasyAdmin ou Sonata. Vérifiez dans security.yaml quels chemins exigent quels rôles, et dans la base de données qui possède ces rôles. Les chemins d'administration qui ne sont nécessaires qu'en interne devraient être limités aux réseaux connus au niveau du serveur web.
Les bundles et paquets Composer sont du code étranger avec ses propres failles. composer audit montre les problèmes connus ; pour plus de détails, voir Vérifier les failles dans les dépendances Composer. Les paquets obsolètes sont en outre la raison la plus fréquente pour laquelle une mise à niveau de PHP prend plus de temps que prévu dans les projets Symfony.
Ce qu'apporte une mise à jour de Symfony et ce qu'elle n'apporte pas
Une mise à jour des composants Symfony comble des défauts du framework. Elle ne corrige pas PHP, ne redémarre pas de workers, ne renouvelle pas de secrets qui ont fuité et ne supprime pas un cache manipulé. Les signes d'une attaque sont décrits dans Suis-je déjà compromis ?. Comme il n'existe aucun indicateur de compromission (IoC) confirmé, c'est surtout l'observation d'un comportement inhabituel qui aide, par exemple des processus inattendus ou des connexions sortantes.
Si le projet est livré sous forme de conteneur, le nouveau PHP doit aller dans l'image de base. Reconstruisez l'image même si le code n'a pas changé et déployez-la dans tous les environnements. Un coup d'œil au Dockerfile montre quelle image de base est utilisée ; un ancien tag fixé empêche sinon la reconstruction de recevoir le PHP corrigé. Les détails figurent sous Corriger PHP dans les conteneurs Docker.
Comment PHP SOS aide-t-il concrètement ?
- Nous établissons quel PHP utilisent le web, la CLI et les workers de votre projet Symfony et accompagnons le redémarrage ordonné.
- Nous sauvegardons les journaux à partir du 20/10/2026 et comparons le code sur le serveur avec votre dépôt.
- Nous contrôlons les fichiers d'environnement, les secrets, le cache, les réglages du profiler et les rôles d'administration.
- Pour la surveillance continue des processus et des connexions, nous proposons la surveillance de sécurité.
Questions fréquentes
Symfony est-il concerné par PHP2Shell ?
Symfony lui-même n'a pas de nouvelle faille. PHP2Shell se trouve dans PHP, donc dans l'environnement d'exécution de toute application Symfony. La faille se comble par une mise à jour de PHP ou un backport confirmé et le redémarrage de tous les processus PHP.
Comment arrêter les workers Messenger après une mise à jour de PHP ?
Avec php bin/console messenger:stop-workers, les workers en cours reçoivent l'instruction de se terminer après le message actuel. Un gestionnaire de processus comme Supervisor ou systemd les redémarre ensuite avec le nouveau PHP.
Pourquoi le profiler Symfony est-il dangereux en production ?
Le profiler montre les requêtes, la configuration et souvent les variables d'environnement. S'il est actif sur un serveur public, n'importe qui peut consulter ces informations. Il n'a sa place que dans l'environnement de développement.
Que devient le cache après une attaque ?
Le cache sous var/cache contient du code PHP généré. Un attaquant peut y déposer du code qui s'exécute à chaque requête. En cas de soupçon, le cache devrait être supprimé et régénéré à partir du code source contrôlé.