Quelques espaces dans un header, et votre serveur PHP s'étouffe
Une requête HTTP anonyme, un header Cache-Control un peu particulier, et un worker PHP passe près d'une seconde à calculer dans le vide. Répétez l'opération et votre application ne répond plus. C'est le scénario permis par la CVE-2026-108082, une faille de type ReDoS découverte dans le composant HttpFoundation de Symfony et détaillée sur le blog officiel de Symfony.
Ce qui se passe réellement
Une expression régulière qui s'emballe
La méthode HeaderUtils::split() découpe la valeur d'un header en éléments. Pour cela, elle s'appuie sur une expression régulière dont l'alternative « token » accepte aussi les espaces, et qui est suivie d'un lookbehind (?<!\s) interdisant qu'un élément se termine par un blanc.
Cette combinaison crée une ambiguïté : une suite d'espaces placée juste avant un séparateur peut être répartie entre les itérations de la répétition englobante d'un nombre exponentiel de façons. Le moteur PCRE les essaie toutes avant de conclure à l'échec. C'est le mécanisme classique du catastrophic backtracking.
Un point d'entrée présent partout
Le point qui rend la faille sérieuse : HeaderBag appelle split() pour le header Cache-Control dès qu'un objet Request est construit. Toute application Symfony qui traite des requêtes HTTP est donc concernée, sans qu'il faille une route particulière, une authentification ou une configuration spécifique.
Les ordres de grandeur
Selon l'avis de sécurité, avec un header d'environ 8 Ko contenant une série de 17 espaces, le traitement coûte environ 813 ms de CPU sur PHP 8.5. Le coût double à chaque espace supplémentaire.
À partir de 18 espaces, preg_match_all() atteint la limite pcre.backtrack_limit et abandonne. split() renvoie alors un tableau vide, ce qui signifie que toutes les directives du header sont silencieusement ignorées. Il y a donc deux effets : une charge CPU forte pour l'attaquant le plus discret, et une perte de lecture des directives de cache pour les cas où la limite est franchie.
Versions concernées et correctifs
Le composant Symfony HttpFoundation est touché dans les branches suivantes :
- de 5.4.1 à 5.4.53, corrigé en 5.4.54
- de 6.0.1 à 6.4.45, corrigé en 6.4.46
- de 7.0 à 7.4.18, corrigé en 7.4.19
- de 8.0 à 8.1.6, corrigé en 8.1.7
Le correctif consiste à rendre l'expression régulière non ambiguë, afin que le moteur n'ait plus à explorer une multitude de découpages équivalents.
Que faire concrètement
- Identifier la version installée :
composer show symfony/http-foundation.
- Mettre à jour vers la version corrigée de votre branche :
composer update symfony/http-foundation.
- Relancer votre suite de tests, puis déployer sans attendre : la faille est exploitable sans authentification.
- Si le déploiement doit patienter, ajouter une limite en amont (reverse proxy, WAF) sur la taille des headers et rejeter les valeurs contenant de longues séries d'espaces consécutifs. C'est une mesure d'atténuation, pas un remplacement du correctif.
- Surveiller la charge CPU et les temps de réponse anormaux sur les requêtes entrantes, qui sont le symptôme typique de ce genre d'attaque.
Une leçon réutilisable
Cette CVE rappelle que les expressions régulières appliquées à des entrées contrôlées par un client sont une surface d'attaque. Dans votre propre code, méfiez-vous des répétitions imbriquées, des alternatives qui se recouvrent et des lookarounds placés après un quantificateur. Des tests avec des entrées pathologiques et une limite stricte sur la taille des données traitées limitent le risque.
En résumé
La CVE-2026-108082 touche un composant central de Symfony, sans condition d'accès : une seule requête bien formée peut coûter près d'une seconde de CPU, et chaque espace de plus double ce coût. Le correctif est disponible dans les versions 5.4.54, 6.4.46, 7.4.19 et 8.1.7. Mettez à jour dès maintenant, et gardez en tête cet avertissement pour vos propres expressions régulières.
Ce que ça change pour vous
Une faille a été trouvée dans une brique utilisée par la grande majorité des sites et applications construits avec Symfony. Elle permet à n'importe qui sur Internet de ralentir fortement votre site, voire de le rendre indisponible, sans avoir besoin d'un compte ni de pirater quoi que ce soit. La correction existe et se résume à une mise à jour que votre équipe technique ou votre prestataire peut appliquer rapidement. Demandez-leur si elle a été faite, et dans quel délai.
