Overview

A vulnerability in Cloudflare’s Front Line (FL) HTTP request header parsing pipeline allowed attackers to bypass all rulesets operating on HTTP headers, manipulate cache behavior, and ultimately perform cache poisoning, forced caching, stored XSS, and Web Application Firewall (WAF) bypass.

The root cause was a hard limit in OpenResty’s header parsing: only the first ~94–100 headers were processed, including internal headers. Additional headers beyond this threshold were silently ignored by FL-layer rulesets, even though Cloudflare continued to forward the request upstream.

This created a discrepancy between the ruleset’s interpretation of the request and the actual request as seen by the cache and the origin, enabling an attacker to introduce malicious headers that Cloudflare would not evaluate.

Cloudflare acknowledged the issue, introduced a global "too many headers" blocking rule, and is migrating to a new Front Line architecture that removes the parsing limit entirely.

Root Cause

Cloudflare’s current Front Line (FL) layer uses OpenResty for request processing. OpenResty imposes a maximum header count limit of 100 total headers, internal + user-provided.

Once the threshold is reached, several behaviors occur:

• Additional headers are not included in the ruleset evaluation.
• Cloudflare rules depending on header values stop functioning.
• Cache Keys no longer consider custom or default keyed headers.
• WAF rules no longer inspect the full set of headers.
• Cache Rules and Cache Bypass logic silently fail.
• Excess headers are forwarded to upstream components or origin servers.

This results in header truncation, reflected by the ruleset field:

Cloudflare documentation notes:

When http.request.headers.truncated is true, rulesets are not seeing all request headers and may fail to enforce protections.

Exploitation Technique

1. Trigger Header Overflow

The attacker sends a request with 94–100 benign headers:

This triggers the truncation condition.

2. Inject Keyed Header After Overflow

After exceeding the limit, the attacker appends the header they intend to manipulate, such as:

or for WAF bypass / stored XSS:

Since these headers appear after the truncation point:

• They are ignored by Cloudflare’s WAF and rulesets.
• They are not part of Cache Key evaluation.
• Cache Rules relying on them fail.
• The origin server still receives and processes them.

This discrepancy enables cache poisoning, forced caching, and WAF bypass.

Impact

1. Cache Key Bypass

When truncation occurs, Cache Key computation stops using any header beyond the parsing limit. This means:

• Custom Cache Key configuration is ignored.
• Default keyed headers (e.g., User-Agent, X-Forwarded-Proto) are ignored.
• Cache segmentation collapses.
• Attackers gain influence over cache behavior.

Incorrect assets may be cached globally and served to all users.

2. Forced Caching of Non-Cacheable Content

Cache Rules that are supposed to prevent caching—such as rules tied to cookies or header values—stop functioning once truncation occurs. Attackers can force Cloudflare to cache:

• private pages
• error messages
• responses containing sensitive content
• dynamic pages not intended for caching

3. Cache Poisoning & Stored XSS

If the origin server uses attacker-controlled headers to generate responses (e.g., reflects User-Agent), Cloudflare may cache the manipulated response.

Under normal conditions, Cloudflare WAF blocks closing tags such as </script>. But these checks fail under truncation.

Example payload:

The origin reflects it, Cloudflare caches it, and the stored XSS is delivered to all subsequent visitors.

4. WAF Bypass

Headers after the truncation point are not inspected. This allows attackers to:

• inject values that would normally be blocked
• bypass signature-based detection
• circumvent custom expressions
• deliver malicious input directly to the origin

Cloudflare confirmed that the current FL platform cannot inspect all headers once truncation occurs.

Proof-of-Concept Examples

Cache Manipulation

This can override method behavior and poison cache variants.

Stored XSS via Header Overflow

If the origin reflects User-Agent, Cloudflare caches the malicious payload.

Detection

Cloudflare exposes this indicator:

This shows that FL rules did not parse the complete header set.

Recommended mitigation:

Cloudflare deployed a global blocking rule implementing this safeguard.

Remediation

Immediate Mitigation

Cloudflare deployed a global "too many headers" blocking rule and updated documentation instructing customers to enforce the truncation detection field. This prevents exploitation on the existing FL pipeline.

Long-Term Mitigation

Cloudflare is rolling out a new Front Line architecture that:

• removes the OpenResty header parsing limit
• ensures WAF inspects all headers
• ensures Cache Rules and Cache Keys use the full header set
• eliminates truncation-based inconsistencies
• synchronizes behavior between Ruleset Engine, cache, and origin

This update permanently resolves the issue.

Conclusion

This vulnerability stemmed from a parsing limitation that caused Cloudflare’s Front Line layer to evaluate only part of the request while forwarding the entire request downstream. By exceeding the header count limit and inserting operational headers after the truncation boundary, attackers could manipulate caching behavior, bypass Cloudflare WAF protections, and produce stored malicious responses.

Cloudflare addressed the issue through immediate rule-based mitigation and is completing a long-term architectural transition to a unified, truncation-free Front Line processing layer. This ensures consistent handling of headers across all enforcement and caching subsystems and eliminates the attack vector entirely.

Centralise your Appsec

A single dashboard for visibility, collaboration, and control across your AppSec lifecycle.

Explore Live Demo