CVE-2026-53878: Django DomainNameValidator HTTP Header Injection – MEDIUM Severity

Technical summary

The vulnerability stems from `DomainNameValidator` failing to strip or reject newline characters in domain name input. Although `CharField` (used in Django forms) automatically removes newlines, applications bypassing form validation and calling `DomainNameValidator` directly may accept domain values containing CR (\r) or LF (\n) sequences. When these unfiltered values are concatenated into HTTP response headers, they enable header injection—an attacker can inject arbitrary headers by embedding newlines in a domain field. The CVSS score of 6.1 (MEDIUM) reflects network-accessible exploitation with user interaction required (UI:R) and limited confidentiality and integrity impact. CWE-144 (Improper Neutralization of Line Delimiters) accurately categorizes the root cause.

Business impact

The practical risk depends on application architecture. Django applications using `DomainNameValidator` in non-form contexts and directly passing validated domains to HTTP headers face header injection risk, potentially enabling session fixation, cache poisoning, or credential theft. Organizations relying on Django for SaaS platforms, multi-tenant systems, or APIs that expose domain configuration in responses should prioritize assessment. However, the requirement for user interaction and the need for deliberate validator misuse (bypassing form layers) limits the immediate blast radius.

Affected systems

Django 6.0.0 through 6.0.6 and Django 5.2.0 through 5.2.15 are confirmed vulnerable. Django 5.2.16 and 6.0.7 or later are patched. Older unsupported series (5.0.x, 4.1.x, 3.2.x) may be affected but have not been formally evaluated by the Django project. Applications remain vulnerable only if they (1) use `DomainNameValidator` directly outside form contexts, (2) fail to sanitize domain values before including them in HTTP headers, and (3) serve responses to untrusted users who can control domain input.

Exploitability

Exploitation requires user interaction: an attacker must induce a victim to interact with an application that accepts attacker-controlled domain input, validates it with a vulnerable Django version, and reflects that input in an HTTP response header. The attack is not remotely triggerable via passive network observation. However, injection payloads are trivial (a newline followed by header syntax), and many developers may not realize that `DomainNameValidator` alone does not guarantee header-safe output. Real-world exploitation would likely target specific high-value integrations or multi-tenant environments where domain fields are user-configurable.

Remediation

Immediately upgrade to Django 5.2.16 or 6.0.7 (or later versions in each series). Review application code for direct usage of `DomainNameValidator` outside form contexts; if found, add explicit newline stripping or reject domain values containing CR/LF. Consider a defense-in-depth approach: validate domains via forms (which strip newlines), and use Django's `HttpResponse` class or middleware to enforce header sanitization. For unsupported Django versions, apply manual patches equivalent to the official fixes or migrate to a supported series.

Patch guidance

Django 5.2.16 and Django 6.0.7 contain fixes that ensure `DomainNameValidator` rejects newline characters. Consult the official Django security advisory and release notes to verify patch content and any accompanying migration steps. Organizations on unsupported versions (4.1.x, 3.2.x, 5.0.x) should verify the patch logic and consider backporting or immediately planning an upgrade to a supported release. Patches are expected to be backward-compatible; apply them during regular maintenance windows unless an application is known to deliberately rely on newlines in domain validation (highly unlikely).

Detection guidance

Search codebase for direct calls to `DomainNameValidator` outside form field definitions. Use SAST tools to flag domain values used in HTTP header construction. Monitor application logs for anomalous domain values containing escaped newlines or CR/LF sequences. Test validation by submitting domain input with embedded newlines (e.g., `example.com\r\nX-Injected-Header: evil`) and verify that the validator rejects or sanitizes the input. After patching, regression-test to confirm that legitimate domain names still validate correctly.

Why prioritize this

This is a MEDIUM-severity vulnerability with limited but real-world applicability. Prioritize remediation if your Django applications accept user-controlled domain input and reflect that input in HTTP headers, or if you maintain shared validation libraries. For typical Django applications using form-based domain input and Django's standard response handling, the practical risk is low. However, the simplicity of the attack pattern and potential for header injection in edge cases warrant timely patching across all affected versions.

Risk score, explained

CVSS 6.1 reflects a network-accessible attack with low complexity and no privileges required, but mandatory user interaction and limited scope (Client/Server separation via UI requirement). Confidentiality and integrity impacts are both marked as Low because successful header injection typically enables targeted attacks (session fixation, cache manipulation) rather than wholesale system compromise. The score is driven by the ease of exploitation and broad affected user base, tempered by the prerequisite for user involvement and the commonplace availability of defenses (form validation, response sanitization).

Frequently asked questions