A limited CRLF injection flaw can be escalated into a severe HTTP desynchronization attack, poisoning CDN caches and delivering XSS payloads to users on legitimate websites.
The attack, called CRLF-Powered Desync, begins when an application incorrectly handles encoded carriage return and line feed characters, commonly represented as %0d%0a.
These characters mark new lines in HTTP messages. If a front-end server decodes them before forwarding a request to a backend server, an attacker may inject new HTTP headers or alter the structure of the upstream request.
One risky configuration involves Nginx deployments that place variables such as $uri in proxy_pass directives. Nginx can normalize and URL-decode the path before forwarding it upstream.
CRLF Desync Poisons CDN Caches
This may convert encoded CRLF sequences into actual line breaks, enabling request header injection. The resulting mismatch between how different infrastructure layers interpret the same request can create an HTTP request smuggling, or desync, condition.
In a desync attack, a front-end proxy and backend application disagree about where one HTTP request ends and the next begins. Attackers can use this confusion to insert an extra request into a shared connection.
Responses intended for one user may be delivered to another, causing account mix-ups, sensitive data exposure, denial of service, or cache poisoning. The researchers showed that the problem can become especially dangerous inside CDN infrastructure.
In one case, response queue poisoning appeared to occur at the CDN layer rather than only within a target application. This created the risk that requests and responses from unrelated sites hosted on the same CDN infrastructure could become mixed.
Such incidents can expose session cookies, authorization tokens, and other sensitive data if connection isolation fails. A more impactful scenario involved poisoning a CDN-cached page and turning the cached content into an XSS delivery mechanism.
By combining a CRLF-powered CL.TE desync with a carefully selected HEAD request behavior, researchers were able to make a CDN cache a malicious response.
The poisoned resource could then be served to live users, allowing attacker-controlled JavaScript to execute in their browser context. The research also warns that these attacks may be browser-compatible.
In some cases, normal browser navigation or JavaScript fetch() requests can carry the crafted encoded data needed to trigger the desync. If an attacker achieves XSS on a victim-facing page, the victim’s browser could repeatedly launch the same malicious requests, creating a self-propagating “desync worm.”
Organizations should treat CRLF and request-header injection as high-severity findings rather than minor input-validation issues.
Defenders should review reverse-proxy rules, avoid using decoded URI variables in Nginx proxy_pass and return directives, and ensure that every layer of the stack applies consistent HTTP parsing rules.
Teams should also test CDN, load balancer, proxy, and origin server behavior together, because the most serious failures arise from parser differences across these layers.
Moving upstream traffic to HTTP/2 where practical, isolating backend connections, rejecting encoded control characters early, and regularly testing for request smuggling can significantly reduce exposure.
The core lesson is simple: a single injected CRLF sequence can become an infrastructure-wide cache poisoning and XSS risk when HTTP components disagree about request boundaries.
Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC