CVE-2026-53878

What it actually does

Django's DomainNameValidator in affected versions permits newline characters in domain-name values when it is used outside form fields that strip newlines. If an application later places such a validated value into an HTTP response header using code that does not reject newline characters, an attacker can cause HTTP response header injection. Django's built-in HttpResponse header handling rejects newlines, so the flaw primarily affects custom response construction, nonstandard header-writing code, middleware, reverse-proxy integration, or third-party components that trust DomainNameValidator output and then emit it into headers.

Why it matters to the business

Applications that accept user-controlled domain names and reflect them into HTTP headers may be exposed to response manipulation, such as setting attacker-chosen cookies, altering redirects, weakening browser security headers, or enabling cache poisoning in some deployment patterns. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has no reported public exploit maturity in the provided data, but it has been public for 35 days and should be addressed during normal security patch cycles, with higher urgency for internet-facing applications that process domain names, redirect targets, callback hosts, tenant domains, or custom headers.

How an attack unfolds

An attacker identifies an application endpoint that accepts a domain-name value and validates it with Django's DomainNameValidator rather than a form CharField. The attacker submits a crafted domain containing a newline sequence followed by a second HTTP header, for example a header that sets a cookie, changes a location, or affects caching behavior. If application code, middleware, or an integration component subsequently writes that value into an HTTP response header without using Django's built-in newline protections, the newline terminates the intended header and the attacker's appended header is interpreted by the client or an intermediary. Successful exploitation requires an application-specific data flow from untrusted input through DomainNameValidator into a vulnerable header sink; Django's normal HttpResponse header APIs are designed to block this sink.

How to fix it

Upgrade Django to a fixed supported release: Django 6.0 users should upgrade to 6.0.7 or later, and Django 5.2 users should upgrade to 5.2.16 or later. Unsupported Django branches such as 5.0.x, 4.1.x, and 3.2.x were not evaluated and should be upgraded to a supported fixed branch rather than relying on backported assumptions. Review application code for any use of DomainNameValidator or custom domain validation where the resulting value is inserted into HTTP headers, redirects, cookies, proxy headers, or response metadata. Ensure all response headers are set through Django's standard response APIs, which reject newline characters. Add explicit validation to reject carriage return and line feed characters in domain-like inputs, including literal '\r' and '\n' and decoded forms of %0d and %0a. Where immediate upgrade is not possible, add server-side input filtering for newline characters in domain fields and avoid reflecting user-controlled values into response headers.

How to confirm the fix worked

Confirm deployed Django versions are 6.0.7 or later for the 6.0 series or 5.2.16 or later for the 5.2 series. Inventory application dependencies with package tooling such as pip freeze, pip show django, poetry show django, pip-audit, or software composition analysis. Search source code for DomainNameValidator usage and verify that any accepted values cannot contain '\r' or '\n' before being used in response headers. Add regression tests that submit domain values containing '\n', '\r', %0a, and %0d%0a and assert that validation fails or the value is safely rejected before response construction. Test vulnerable-looking endpoints with a harmless injected header in a non-production environment and confirm the injected header is not present in the HTTP response. Verify that unsupported Django versions have been removed or isolated from internet-facing traffic.

Typical attack path

1. Find an application feature that accepts domain-like input, such as callback domains, custom hostnames, redirect domains, webhook domains, or tenant domains.
2. Submit test values containing URL-encoded or literal newline characters, such as %0a or %0d%0a, and observe whether the value is accepted.
3. Determine whether the accepted domain value is later reflected into an HTTP response header, redirect, cookie, cache-control path, or proxy-generated header.
4. Craft a payload that injects an additional response header after the newline.
5. Trigger the vulnerable response path and verify whether the client, browser, cache, or proxy processes the injected header.
6. Use the injected header to manipulate browser behavior, set or overwrite cookies, poison caches, or alter downstream request handling depending on the affected application's response flow.

How to detect it

Look for evidence that attackers submitted newline or CRLF sequences in domain-like parameters and that those values influenced response headers. Relevant log sources include application request logs, Django access/error logs, web server logs, reverse-proxy logs, CDN/WAF logs, API gateway logs, and full HTTP capture where available. Search for URL-encoded newline sequences such as %0a, %0d, %0d%0a, double-encoded variants such as %250a and %250d%250a, and literal escaped newline representations in parameters named or used like domain, hostname, host, redirect, callback, return, next, webhook, origin, site, or tenant. Correlate suspicious requests with anomalous response headers, unexpected Set-Cookie headers, unusual Location redirects, cache behavior changes, or browser security headers that differ from the expected baseline. Review application logs for validation successes on domain strings containing control characters and for exceptions or warnings from response/header construction. Because Django's own HttpResponse rejects newline characters in headers, prioritize custom middleware, streaming responses, raw WSGI/ASGI header handling, reverse-proxy header generation, and third-party packages that may bypass Django's standard protections.

• %0d%0aSet-Cookie:
• %0aSet-Cookie:
• %0d%0aLocation:
• %0aLocation:
• %0d%0aContent-Security-Policy:
• %0aContent-Security-Policy:
• %0d%0aCache-Control:
• %0aCache-Control:
• %0d%0aX-Forwarded-Host:
• %0aX-Forwarded-Host:
• %250d%250aSet-Cookie%3A
• %250aSet-Cookie%3A
• \r\nSet-Cookie:
• \nSet-Cookie:
• \r\nLocation:
• \nLocation:
• Invalid HTTP Header: Header values can't contain newlines
• Header values can't contain newlines

What your security team should do

• Prioritize patching internet-facing Django applications that accept domain, hostname, redirect, callback, tenant, or webhook configuration from users.
• Upgrade affected supported releases to Django 6.0.7 or later or 5.2.16 or later; migrate unsupported Django branches to a supported fixed version.
• Ask engineering teams to review code paths using DomainNameValidator and any custom HTTP header construction, especially outside Django's standard HttpResponse header APIs.
• Deploy or confirm input validation that rejects carriage return and line feed characters in domain-like fields at API, form, and model boundaries.
• Add automated tests for CRLF/header-injection payloads in endpoints that accept hostnames or domains.
• Review web, application, CDN, reverse-proxy, and WAF logs for newline-encoded payloads in parameters associated with domains, redirects, callbacks, or hostnames.
• Create SIEM detections for URL-encoded newline sequences combined with header names such as Set-Cookie, Location, Content-Security-Policy, Cache-Control, or X-Forwarded-Host.
• Treat evidence of successful injected Set-Cookie, Location, or cache-related headers as a potential session, redirect, or cache-poisoning incident and investigate affected user traffic.