Unauthenticated Whitespace Requests Freeze Symfony Apps, Drop Cache Headers in ReDoS Vulnerability

An unauthenticated HTTP request can now exhaust CPU resources or silently discard cache directives in vulnerable versions of the Symfony PHP framework. The issue stems from a regular expression denial of service flaw in the HeaderUtils component, specifically within the split function. This vulnerability affects applications handling web requests without requiring any form of user authentication or prior session establishment.

The National Vulnerability Database assigns CVE-2026-108082 a CVSS score of 8.7, classifying the severity as High. The flaw exists in the pattern used to parse header values, where a token alternative matches whitespace followed by a negative lookbehind assertion. This combination allows an attacker to craft a header with a specific run of whitespace characters before a separator. The regex engine then attempts to divide this whitespace among iterations in exponentially many ways, consuming significant processing power before settling on a result.

Context and Background

According to the NVD record, the HeaderBag component calls this vulnerable function whenever a Request object is built, making any application processing HTTP requests reachable. A single request carrying a crafted header can consume close to a second of CPU time. Testing on PHP 8.5 showed that 17 spaces in an 8 KB header resulted in 813 milliseconds of processing, with the cost doubling for each additional space added to the sequence.

This issue affects symfony/http-foundation versions starting from v4.1.0-BETA1 up to, but not including, v5.4.54. It also impacts v6.0.0-BETA1 through v6.4.46, v7.0.0-BETA1 through v7.4.19, and v8.0.0-BETA1 through v8.1.7. The underlying weakness is classified as CWE-1333, which relates to improper handling of input that leads to excessive resource consumption. The exponential nature of the backtracking means that minor increases in input complexity lead to disproportionate spikes in computational demand.

Who is affected

Any web application built on the Symfony framework is potentially reachable by this attack vector. The flaw is triggered automatically during the construction of a Request object, meaning no special user interaction or complex payload injection is required beyond sending a standard GET request. A report on r/netsec noted that common configurations can turn this regular expression denial of service into a real denial of service, with roughly 100 requests potentially causing an application to time out.

The silent data loss aspect of the vulnerability becomes active when the number of spaces reaches 18 or more. At this threshold, the preg_match_all function gives up due to the pcre.backtrack_limit configuration setting. Consequently, the split function returns an empty array, causing every directive within the Cache-Control header to be silently dropped. This results in the application ignoring caching instructions entirely, which could lead to performance degradation or incorrect content delivery, even if the server does not crash.

What should you do?

Security teams should immediately audit their infrastructure to identify any systems running vulnerable versions of the Symfony framework. Since the attack requires no authentication, public-facing endpoints are at immediate risk. Administrators should monitor server logs for unusual CPU spikes or requests containing excessive whitespace in header fields. Until a vendor update is available, consider implementing rate limiting or input validation at the reverse proxy level to mitigate the impact of such requests.