Summary

A limitation in our HTTP request header parsing in Front Line (FL) processing enables attackers to bypass defined rulesets. The maximum amount of headers being parsed by openresty is 100 HTTP headers including internal ones. This problem applies to any ruleset on HTTP headers. Attackers are able to bypass for instance WAF rules and perform cache forcing/poisoning. Our WAF team implemented a global rule to block, when too many headers were provided (https://developers.cloudflare.com/changelog/2025-10-20-waf-release/), which is recommended to be enabled. We want to emphasize that https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/http.request.headers.truncated/ indicates if rulesets is not seeing all the request headers. Moreover, the length problem of parsed HTTP headers will be mitigated with the rollout of our new Front Line implementation.

Summary

A vulnerability in HTTP request header processing allowed attackers to exploit cache poisoning attacks on all Cloudflare customers. By appending a keyed header after an overflow triggered by exceeding 94 headers, attackers could manipulate cache behavior.

• The vulnerability enabled attackers to bypass Cloudflare’s Cache Key configuration, refer to Cloudflare Cache Key documentation. Both custom and default keyed headers were excluded from the Cache Key evaluation when the header count exceeded 94.

• This also allowed attackers to force caching of assets not intended for caching, bypassing Cache Rules. For example, responses configured to avoid caching based on specific headers or cookies were cached.

• When the header count surpassed 94, Cloudflare’s evaluation of Cache Rules, Custom Cache Keys, and Default Cache Keys ceased.

e.g

[94+ headers with arbitrary data]
1: 1
1: 1
1: 1
1: 1
1: 1
1: 1
X-HTTP-Method-Override: HEAD
Host: victim.com
...

Attackers could add a header initially in the cache key (e.g., X-HTTP-Method-Override) to manipulate the response and cache incorrect or malicious content to be served in subsequent responses.

This led to cache poisoning denial of service, and stored XSS attacks.

WAF Bypass

Attackers could also bypass Cloudflare’s Web Application Firewall (WAF) and both custom and managed firewall rules, allowing malicious requests to reach the origin server uninspected.

This vulnerability could be exploited to achieve stored XSS through cache poisoning and WAF bypass. For example, consider a website with a strict rule that prohibits closing tags (e.g., </tag>) and reflects the User-Agent header in its responses. The website's WAF returns a 403 error page if the request lacks the header overflow. By manipulating the User-Agent an attacker could chain these issues to poison the cache, and achieve stored XSS.

[94+ headers with arbitrary data]
1: 1
1: 1
1: 1
1: 1
1: 1
1: 1
User-Agent: </script><svg onload=alert(1)>
Host: victim.com
...

Current Front Line (FL) Behavior:

As noted in the Cloudflare Ruleset Engine documentation, the current Front Line does not mitigate this issue. Header truncation detection (http.request.headers.truncated) is recommended to identify and block requests with excessive headers: https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/http.request.headers.truncated/

Hi @david96, w.r.t WAF bypass - the behavior will stay like this with the current Front Line (FL): https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/http.request.headers.truncated/ After a full migration to our new Front Line layer, WAF will have the capability to inspect/block all headers...

This report was awarded $1,250