--- title: 'Symfony : dix avis de sécurité publiés le même jour, comment vérifier ton exposition' description: "Le 4 novembre 2026, Symfony a publié dix avis de sécurité dans plusieurs composants, dont une faille de génération d'URL qui peut envoyer tes identifiants vers un autre hôte : voici comment savoir si tu es concerné et quoi mettre à jour." pubDate: 2026-11-10 family: 'php-symfony' tags: [] faq: - question: 'Un seul numéro de version corrige-t-il les dix avis du 4 novembre 2026 ?' answer: "Non. Les avis portent sur des composants différents (HTTP Foundation, YAML, Filesystem, Serializer, HTTP Client, Security HTTP, HTTP Kernel) et chacun publie ses propres plages de versions affectées et corrigées. La série 5.4.56, 6.4.50, 7.4.23 et 8.1.11 concerne la plupart d'entre eux, mais pas tous : l'avis JSON Path, par exemple, n'est corrigé qu'en 7.4.23 et 8.1.11. Lis la section « Affected versions » de chaque avis." - question: 'framework.trusted_hosts protège-t-il de GHSA-5mx8-mwrp-5693 ?' answer: "Non. L'avis est explicite : l'hôte de la requête est le vrai hôte de ton application, donc la liste des hôtes de confiance le valide. Ce sont les URL générées qui pointent ailleurs. La protection vient du correctif de Request::getBaseUrl(), pas de la configuration des hôtes de confiance." - question: 'Comment vérifier rapidement si mon application est vulnérable à GHSA-5mx8-mwrp-5693 ?' answer: "Lance composer show symfony/http-foundation pour connaître la version installée, puis compare-la aux plages de l'avis. Vérifie ensuite si ton front controller est dans un sous-dossier et si ton serveur web lui envoie des URI qui ne commencent pas par ce dossier, ou s'il définit SCRIPT_NAME sur le chemin de la requête. Les configurations recommandées par la documentation Symfony ne sont pas affectées." --- Le 4 novembre 2026, l'équipe sécurité de Symfony a publié **dix avis GHSA le même jour**. Ils ne visent pas un paquet unique : HTTP Foundation, YAML, Filesystem, Serializer, HTTP Client, Security HTTP et HTTP Kernel sont concernés, chacun avec ses propres versions corrigées. Un seul mérite une lecture immédiate, parce qu'il transforme un lien forgé en vol d'identifiants : **GHSA-5mx8-mwrp-5693**, « Generated URLs Can Point to a Host Chosen by the Client ». Aucune commande de cet article n'a été exécutée pour l'écrire, et aucune application n'a été testée ici. Les faits viennent de la [page de l'avis GHSA-5mx8-mwrp-5693](https://symfony.com/blog/ghsa-5mx8-mwrp-5693-generated-urls-can-point-to-a-host-chosen-by-the-client) et de la [liste des avis de sécurité du 4 novembre 2026](https://symfony.com/blog/category/security-advisories), toutes deux consultées le 10 novembre 2026. ## La faille à retenir : une URL générée peut pointer vers l'hôte du client L'avis est signé Fabien Potencier et crédite Nicolas Grekas pour le signalement et le correctif. Il touche **symfony/http-foundation** dans les versions inférieures à 5.4.56, les 6.x inférieures à 6.4.50, les 7.x inférieures à 7.4.23 et les 8.x inférieures à 8.1.11. Le correctif est publié en 5.4.56, 6.4.50, 7.4.23 et 8.1.11, puis porté sur la branche 8.2. ### Le mécanisme `Request::getBaseUrl()` sert à retrouver la partie de l'URL qui précède le script PHP. Quand le nom du script n'apparaît pas au début de l'URI de la requête, la méthode le cherche plus loin dans le chemin. Ce comportement existe pour les serveurs qui réécrivent toutes les URL vers un front controller placé dans un sous-dossier, par exemple `public/index.php`. Le problème est que la base URL conserve **tout ce qui précède le nom du script**, et que cette partie vient du client. Si l'URI commence par deux barres obliques ou par une barre oblique suivie d'une barre inversée, la base URL commence elle aussi par un hôte. La base path est dérivée de la même valeur. ### Le scénario, étape par étape Avec `SCRIPT_NAME` réglé sur `/public/index.php` : 1. L'attaquant forge un lien du type `https://app.example//evil.example/public/index.php/login` et le fait suivre à un utilisateur, par exemple dans un e-mail de phishing. 2. Le serveur web transmet l'URI au front controller. Le routeur reconnaît `/login` et affiche la page de connexion normale. 3. `getBaseUrl()` renvoie `//evil.example/public/index.php` et la base path `//evil.example/public`. 4. Les URL générées pour cette page commencent désormais par `//evil.example`, que le navigateur interprète comme un autre hôte. 5. L'utilisateur saisit ses identifiants dans ce qui ressemble au formulaire habituel. L'action du formulaire pointe vers `evil.example`, et les identifiants partent chez l'attaquant. ### Ce qui fuit concrètement L'avis liste trois familles d'URL affectées : - les liens construits avec `path()` et les actions de formulaires, donc un formulaire de connexion qui envoie les identifiants à l'attaquant ; - les redirections vers des URL générées, notamment celles de `redirectToRoute()` ; - les assets référencés en chemin relatif via `asset()`, ce qui permet à la page de charger des scripts depuis `evil.example`. Le troisième point est le plus discret : la page reste servie par ton domaine, mais son JavaScript peut venir d'ailleurs. ### Pourquoi trusted_hosts ne te sauve pas `framework.trusted_hosts` valide l'hôte de la **requête**. Or ici, la requête arrive bien sur ton vrai domaine : c'est `app.example` qui la reçoit. La liste des hôtes de confiance ne voit rien d'anormal. Le correctif porte sur la génération des URL, pas sur la validation de la requête entrante. ### Quand tu es exposé L'avis décrit trois configurations à risque : - **Front controller dans un sous-dossier** avec un serveur qui envoie des URI ne commençant pas par ce dossier. Un `.htaccess` à la racine du projet qui réécrit toutes les URL vers `public/` correspond à ce cas. - **`SCRIPT_NAME` défini sur le chemin de la requête.** Certaines configurations nginx le font quand toutes les requêtes partent vers le front controller sans `fastcgi_split_path_info`. - **`php -S` avec un script de routage hors du document root.** Une requête vers `/\evil.example/index.php` produit une base URL que le navigateur lit comme un lien vers `evil.example`. À l'inverse, l'avis précise que **les configurations recommandées dans la documentation Symfony ne sont pas affectées**. Si tu suis le `.htaccess` de `symfony/apache-pack` ou la configuration nginx documentée, tu n'es pas dans les cas décrits. ## Les neuf autres avis Chaque avis indique lui-même son composant, ses plages de versions affectées et ses versions corrigées. Les versions ne sont donc pas interchangeables d'un avis à l'autre : la liste ci-dessous reprend le composant et le risque, et le lien mène à la section « Affected versions » de l'avis. - **[GHSA-3h27-hjv7-fqjx](https://symfony.com/blog/ghsa-3h27-hjv7-fqjx-path-rules-enforced-in-front-of-php-can-be-bypassed-by-appending-the-path-to-the-script-name)** : HTTP Foundation. Depuis le correctif de CVE-2025-64500, `getPathInfo()` retire le nom du script même quand il n'est que le début d'un segment plus long, si bien que `/index.phpadmin` est routé comme `/admin` et contourne les règles appliquées devant PHP (nginx, Apache, CDN ou WAF). Corrigé en 5.4.56, 6.4.50, 7.4.23 et 8.1.11. - **[GHSA-cpww-5vpx-72x7](https://symfony.com/blog/ghsa-cpww-5vpx-72x7-incomplete-fix-for-cve-2026-45756-jsonpath-search-match-and-chained-filters-can-hold-a-process)** : JSON Path. Le correctif de CVE-2026-45756 ne bornait pas le coût réel des filtres `search()` et `match()`, et des requêtes sans expression régulière pouvaient faire croître le temps de calcul plus vite que leur taille. Corrigé en 7.4.23 et 8.1.11 seulement. - **[GHSA-hwfg-qwvh-2wfx](https://symfony.com/blog/ghsa-hwfg-qwvh-2wfx-exponential-and-quadratic-parse-times-in-the-yaml-parser-let-a-single-document-hold-a-process)** : YAML. Un document de 93 octets pouvait occuper un processus PHP pendant 15 secondes, et d'autres motifs de 128 ou 200 Ko coûtaient plusieurs secondes. Corrigé en 5.4.56, 6.4.50, 7.4.23 et 8.1.11. - **[GHSA-6prc-h956-hxjq](https://symfony.com/blog/ghsa-6prc-h956-hxjq-filesystem-path-treats-any-prefix-before-as-a-root-letting-paths-escape-their-base-directory)** : Filesystem. `Path::split()` prend tout ce qui précède `://` pour une racine sans vérifier qu'il s'agit d'un schéma d'URI, ce qui permet à un chemin de sortir de son répertoire de base. Corrigé en 5.4.56, 6.4.50, 7.4.23 et 8.1.11. - **[GHSA-pxj9-jh84-vhm5](https://symfony.com/blog/ghsa-pxj9-jh84-vhm5-dataurinormalizer-opens-data-uris-with-a-non-lowercase-scheme-as-local-files)** : Serializer. `DataUriNormalizer` accepte `DATA:` ou `Data:` sans tenir compte de la casse, mais PHP n'ouvre le flux `data:` qu'en minuscules : l'entrée est alors lue comme un chemin local, ce qui permet de lire un fichier du serveur. Corrigé en 5.4.56, 6.4.50, 7.4.23 et 8.1.11. - **[GHSA-c7hm-wqwp-f9v8](https://symfony.com/blog/ghsa-c7hm-wqwp-f9v8-noprivatenetworkhttpclient-does-not-pin-the-ip-of-cached-hosts-incomplete-fix-for-cve-2024-50342)** : HTTP Client. `NoPrivateNetworkHttpClient` n'épinglait l'IP que lors de la première résolution d'un hôte ; les requêtes suivantes laissaient le client résoudre à nouveau, ce qui rouvre le rebinding DNS pour énumérer des ports internes. Corrigé en 5.4.56, 6.4.50, 7.4.23 et 8.1.11. - **[GHSA-8f57-m8wj-x65w](https://symfony.com/blog/ghsa-8f57-m8wj-x65w-programmatic-logins-skip-the-checkpostauth-method-of-user-checkers)** : Security HTTP. `Security::login()` et `authenticateUser()` n'appelaient pas `checkPostAuth()` du user checker, si bien qu'un compte expiré pouvait être connecté programmatiquement alors que le formulaire de connexion le refusait. Corrigé en 5.4.56, 6.4.50, 7.4.23 et 8.1.11. - **[GHSA-wg5q-m2ww-f3c9](https://symfony.com/blog/ghsa-wg5q-m2ww-f3c9-inline-fragments-let-untrusted-forwarded-headers-change-the-urls-generated-for-the-main-request)** : HTTP Kernel. Pendant le rendu d'un fragment inline, `127.0.0.1` est ajouté temporairement aux proxys de confiance ; si la requête principale vient de cette adresse, ses en-têtes X-Forwarded et Forwarded sont alors crus et fixent l'hôte, le schéma et le port des URL absolues générées ensuite. Corrigé en 5.4.56, 6.4.50, 7.4.23 et 8.1.11. - **[GHSA-gq53-v8w2-gjhj](https://symfony.com/blog/ghsa-gq53-v8w2-gjhj-scopinghttpclient-sends-its-default-scope-credentials-to-other-origins-via-network-path-references)** : HTTP Client. Une URL relative de type `//evil.example/steal` conserve les options du scope par défaut, dont `auth_bearer`, après résolution vers un autre origin : les identifiants partent chez l'attaquant. Corrigé en 5.4.56, 6.4.50, 7.4.23 et 8.1.11. Deux avis concernent donc HTTP Foundation et deux concernent HTTP Client, mais avec des versions affectées qui ne se superposent pas toujours : pour GHSA-3h27, les plages commencent à 5.4.50, 6.4.29 et 7.3.7. C'est une raison de plus pour lire chaque bulletin plutôt que de se fier à un numéro unique. ## Suis-je exposé ? La commande de base pour le composant principal : ```bash composer show symfony/http-foundation ``` Elle affiche notamment la version installée. Compare-la aux plages de l'avis : | Branche | Versions vulnérables | Version corrigée | | ------- | -------------------- | ---------------- | | 5.4 | inférieures à 5.4.56 | 5.4.56 | | 6.x | 6.0.0 à 6.4.49 | 6.4.50 | | 7.x | 7.0.0 à 7.4.22 | 7.4.23 | | 8.x | 8.0.0 à 8.1.10 | 8.1.11 | La branche 8.2 a reçu le portage du correctif. Si ton `composer.lock` épingle une version plus ancienne, la commande le montre aussi. Vient ensuite la question de la configuration. Pose-toi ces trois questions : 1. Ton front controller est-il dans un sous-dossier, par exemple `public/index.php`, alors que les URL publiques n'incluent pas ce dossier ? 2. Ton serveur web envoie-t-il au front controller des URI qui ne commencent pas par ce sous-dossier, via une réécriture à la racine ? 3. Ta configuration nginx définit-elle `SCRIPT_NAME` sur le chemin de la requête, sans `fastcgi_split_path_info` ? Utilises-tu `php -S` avec un script de routage hors du document root ? Une réponse positive suffit à justifier une mise à jour rapide. Une réponse négative partout, avec une configuration alignée sur la documentation Symfony, correspond aux cas que l'avis déclare non affectés. ## Corriger Les commandes ci-dessous sont celles que documente Composer ; elles n'ont pas été exécutées pour cet article et aucune sortie n'est reproduite ici. ```bash composer update symfony/http-foundation ``` Si ton projet verrouille cette dépendance par une autre bibliothèque, la mise à jour peut être refusée : dans ce cas, traite le conflit plutôt que de forcer. Pour aligner plusieurs composants Symfony, `composer update` sur l'ensemble du projet fonctionne, mais relis le diff du `composer.lock` avant de committer : une mise à jour de sécurité ne doit pas embarquer une montée de version majeure non voulue. Ensuite, vérifie le résultat et l'état global : ```bash composer show symfony/http-foundation composer audit ``` `composer audit` compare les dépendances installées aux avis publiés et liste celles qui restent vulnérables. Il ne remplace pas la lecture des avis : une alerte peut concerner un paquet que tu n'utilises pas dans un chemin exposé, et inversement une configuration particulière peut t'exposer même avec une version à jour. Après le déploiement, vide le cache de production si ton déploiement ne le fait pas déjà : ```bash php bin/console cache:clear --env=prod ``` Enfin, teste le correctif sur un environnement de recette avec une URI forgée du type `//evil.example/public/index.php/login` : la page doit se charger et les URL générées doivent rester sur ton domaine. Ce test fait partie de la vérification recommandée, il n'a pas été exécuté ici. ## Ce que ça change dans le code Le correctif ferme le cas connu, mais l'avis rappelle une règle utile au-delà de cette faille : ne construis pas d'URL absolue à partir d'une valeur brute fournie par le client. Si ton application lit `REQUEST_URI`, `HTTP_HOST` ou un paramètre de retour pour fabriquer une redirection, valide le résultat contre une liste blanche de chemins ou d'hôtes. Pour les applications qui ne peuvent pas mettre à jour immédiatement, un rejet en amont des URI commençant par `//` ou `/\` réduit l'exposition. C'est une mesure de contournement, pas un remplacement du correctif : elle doit être retirée une fois la mise à jour faite, sinon elle masque le comportement réel du framework. Si tu veux auditer le reste de ton application après cette vague d'avis, la démarche est proche de celle décrite dans [ma découverte de Symfony Security Auditor](/blog/decouverte-de-symfony-security-auditor/). Et si tu dois arbitrer entre plusieurs correctifs PHP en attente, [le récapitulatif des failles RCE critiques de PHP](/blog/failles-rce-critiques-php-versions-corrigees-et-mitigations/) donne la méthode pour prioriser selon l'exposition réelle. ## Questions fréquentes **Un seul numéro de version corrige-t-il les dix avis du 4 novembre 2026 ?** Non. Les avis portent sur des composants différents (HTTP Foundation, YAML, Filesystem, Serializer, HTTP Client, Security HTTP, HTTP Kernel) et chacun publie ses propres plages de versions affectées et corrigées. La série 5.4.56, 6.4.50, 7.4.23 et 8.1.11 concerne la plupart d'entre eux, mais pas tous : l'avis JSON Path, par exemple, n'est corrigé qu'en 7.4.23 et 8.1.11. Lis la section « Affected versions » de chaque avis. **framework.trusted_hosts protège-t-il de GHSA-5mx8-mwrp-5693 ?** Non. L'avis est explicite : l'hôte de la requête est le vrai hôte de ton application, donc la liste des hôtes de confiance le valide. Ce sont les URL générées qui pointent ailleurs. La protection vient du correctif de Request::getBaseUrl(), pas de la configuration des hôtes de confiance. **Comment vérifier rapidement si mon application est vulnérable à GHSA-5mx8-mwrp-5693 ?** Lance composer show symfony/http-foundation pour connaître la version installée, puis compare-la aux plages de l'avis. Vérifie ensuite si ton front controller est dans un sous-dossier et si ton serveur web lui envoie des URI qui ne commencent pas par ce dossier, ou s'il définit SCRIPT_NAME sur le chemin de la requête. Les configurations recommandées par la documentation Symfony ne sont pas affectées.