CVE-2026-53878: Django Header Injection Vulnerability

CVE-2026-53878 Overview

CVE-2026-53878 affects the Django web framework, where DomainNameValidator does not prohibit newline characters in domain names. Applications that pass validated domain values into HTTP response headers can suffer HTTP header injection [CWE-144]. Django itself remains unaffected because HttpResponse blocks newlines in headers, but downstream application code that constructs responses manually is exposed.

The issue impacts Django 6.0 before 6.0.7 and Django 5.2 before 5.2.16. Earlier unsupported branches (5.0.x, 4.1.x, 3.2.x) were not evaluated and may also carry the flaw. Bence Nagy reported the issue to the Django project.

Critical Impact
Attackers can inject carriage return and line feed sequences through validated domain names, enabling response splitting, cache poisoning, and cross-site scripting when applications reflect the value into HTTP headers.

Affected Products

Django 6.0 before 6.0.7
Django 5.2 before 5.2.16
Unsupported Django series (5.0.x, 4.1.x, 3.2.x) potentially affected but not evaluated

Discovery Timeline

Vulnerability reported to Django by Bence Nagy
2026-07-07 - Django publishes security releases 6.0.7 and 5.2.16
2026-07-07 - CVE-2026-53878 published to NVD
2026-07-09 - Last updated in NVD database

Technical Details for CVE-2026-53878

Vulnerability Analysis

The flaw resides in Django's DomainNameValidator, which validates domain-name strings without rejecting newline characters (\r and \n). When developers call the validator directly on data sourced from user input, JSON payloads, or API parameters, embedded newlines pass validation unchanged. Applications that then place the validated string into an HTTP response header can leak attacker-controlled CRLF sequences into the response stream.

Django's built-in HttpResponse object sanitizes header values and blocks newlines, so the core framework is not exploitable on its own. The risk surfaces in application code that constructs raw headers, writes to WSGI/ASGI response objects directly, or emits domain values through third-party middleware that lacks the same guardrail. The validator is also bypassed when used through a CharField form field, since CharField strips newlines before validation, narrowing the vulnerable code paths to non-form contexts.

Root Cause

The root cause is missing input sanitization inside DomainNameValidator. The regular expression permits characters that should never appear in a valid domain, including \r and \n. This maps to CWE-144: Improper Neutralization of Line Delimiters. Validation logic assumed callers would strip control characters, but that assumption does not hold when the validator is used outside form processing.

Attack Vector

An attacker supplies a domain-like string containing URL-encoded or literal \r\n characters through any input surface an application routes to DomainNameValidator. If the application later writes that string into a response header, such as Location, Set-Cookie, or a custom header, the injected newlines terminate the header and let the attacker append arbitrary headers or a full response body. Exploitation requires user interaction and depends on the application's handling of the validated value.

See the Django Weblog Security Releases for the vendor's technical description of the fix.

Detection Methods for CVE-2026-53878

Indicators of Compromise

HTTP request parameters or JSON fields containing %0d%0a, %0a, or literal \r\n sequences alongside domain-shaped values
Response logs showing duplicate header names or unexpected header injection following user-supplied domain inputs
Web application firewall alerts flagging CRLF patterns in fields expected to carry hostnames or email domains

Detection Strategies

Inventory Django deployments and confirm versions against 6.0.7 and 5.2.16 using pip show django or dependency manifests
Audit application code for direct calls to DomainNameValidator outside CharField-based forms, especially in Django REST Framework serializers and custom validators
Scan HTTP access logs for URL-encoded newline patterns in query parameters and POST bodies targeting endpoints that accept domain input

Monitoring Recommendations

Alert on outbound responses containing header injection patterns such as unexpected Set-Cookie or Location values that correlate with recent user input
Log validator invocations in development and staging environments to surface non-form usage of DomainNameValidator
Integrate Django security release feeds into vulnerability management workflows to catch future advisories quickly

How to Mitigate CVE-2026-53878

Immediate Actions Required

Upgrade to Django 6.0.7 or Django 5.2.16 as documented in the Django Security Release Documentation
Review all direct uses of DomainNameValidator and confirm callers strip or reject newline characters before passing values to response headers
Migrate applications running unsupported Django series (5.0.x, 4.1.x, 3.2.x) to a supported release, since those branches were not evaluated for this issue

Patch Information

Django released fixed versions 6.0.7 and 5.2.16 on 2026-07-07. Both releases update DomainNameValidator to reject newline characters. Release notes and download links are available from the Django Weblog Security Releases.

Workarounds

Wrap DomainNameValidator in a custom validator that calls value.replace('\r', '').replace('\n', '') or rejects any input containing control characters
Route domain input through a Django CharField form field, which strips newlines before validation reaches the validator
Ensure application response code uses HttpResponse header assignment rather than writing raw bytes to the response stream, since HttpResponse blocks CRLF injection

bash

# Upgrade Django to a fixed release
pip install --upgrade "Django>=6.0.7,<6.1"
# or for the 5.2 series
pip install --upgrade "Django>=5.2.16,<5.3"

# Verify installed version
python -c "import django; print(django.get_version())"