CRLF trick lets attackers poison CDN caches with XSS

Published August 17, 2026

Researchers found a way to abuse a common Nginx server setup so an attacker's request confuses the website and its backend about where one request ends and another begins. That confusion can let an attacker plant malicious code in a CDN's cache, so it gets served to every visitor who loads that page afterward.

Report priority
High
Involves
Nginx

What is known

  • An attacker sends a web request containing encoded carriage-return and line-feed characters (%0d%0a) hidden in a URL.
  • If the Nginx configuration forwards that URL through a variable like $uri in a proxy_pass rule, Nginx decodes those characters into real line breaks before passing the request, letting the attacker sneak in extra HTTP headers and split it...

What to do

Instead, review any Nginx configuration you run for proxy_pass or return directives that use decoded URI variables such as $uri, since that pattern is what makes the desync possible.

Rewrite those Nginx rules to avoid passing decoded URI variables into proxy_pass or return directives, reject encoded control characters at the edge, keep HTTP parsing consistent across your CDN, load balancer, proxy, and origin, and test the whole chain for request smuggling. There is no vendor patch to install for this configuration-driven issue.

Reported details

Researchers demonstrated the technique against a TikTok domain that used this kind of Nginx proxy configuration. They sent a request with the hidden CRLF characters, which caused the front-end and backend to disagree about where the request ended, splitting in an extra hidden request. By pairing that with a specific HEAD request response, they got a shared CDN cache to store a malicious response and could have used it to intercept other users' traffic, including newly uploaded private video clips.

The technique, dubbed CRLF-Powered Desync, escalates a low-severity CRLF injection into an HTTP request smuggling (CL.TE desync) condition when Nginx URL-decodes a variable like $uri before proxying it upstream. This can produce response queue poisoning, where responses meant for one visitor are delivered to another, and in CDN environments the desync can occur at the shared CDN layer, mixing traffic from unrelated sites on the same infrastructure. Combined with a crafted HEAD request, attackers can get a CDN to cache a malicious, XSS-laden response and serve it to all subsequent visitors, and because some triggers are reachable from ordinary browser navigation or fetch calls, a successful XSS could re-trigger the desync in other visitors' browsers, creating a self-propagating desync worm.

References

View Original Source