CVE-2026-3902: 
Django vulnerability analysis and mitigation

CVE-2026-3902 is a header spoofing vulnerability in Django's ASGIRequest handler, allowing remote attackers to spoof HTTP headers by exploiting an ambiguous mapping between header variants using hyphens and underscores, both of which are normalized to a single underscore-based representation. It affects Django 4.2 before 4.2.30, 5.2 before 5.2.13, and 6.0 before 6.0.4; earlier unsupported series (5.0.x, 4.1.x, 3.2.x) may also be affected. The vulnerability was disclosed on April 7, 2026, and was reported by Tarek Nakkouch. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Django Blog).

The root cause is an inconsistent normalization of HTTP header names within Django's ASGI request handling layer (ASGIRequest), classified as CWE-290 (Authentication Bypass by Spoofing) and CWE-444 (Inconsistent Interpretation of HTTP Requests) (GitHub Advisory, Feedly). When Django processes ASGI requests, headers containing hyphens (e.g., X-Forwarded-For) and headers containing underscores (e.g., X_Forwarded_For) are both mapped to the same internal underscore-based key. An attacker can exploit this ambiguity to inject or override security-sensitive headers that downstream application logic or middleware trusts for authentication or access control decisions. The fix is tracked in Django's changeset a623c39 (Django Changeset).

Successful exploitation allows a remote, unauthenticated attacker to spoof HTTP headers in ASGI-based Django applications, potentially bypassing authentication mechanisms, circumventing IP-based access controls, or escalating privileges if the application relies on header values (e.g., X-Forwarded-For, X-Real-IP, or custom auth headers) for security decisions (GitHub Advisory, Feedly). The CVSS score reflects a high integrity impact with no confidentiality or availability impact, meaning the primary risk is unauthorized modification of trust relationships rather than data exfiltration or service disruption. Applications using WSGI (not ASGI) are not affected by this specific issue.

There is no public proof-of-concept exploit and no confirmed in-the-wild exploitation as of the time of reporting (Feedly). The EPSS score is approximately 0.016–0.036%, placing it in a low percentile for near-term exploitation likelihood (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported. However, the low attack complexity and lack of required privileges or user interaction make it straightforward to exploit if an attacker understands the header normalization behavior.

1. Identify target: Locate a Django application running in ASGI mode (e.g., using Daphne, Uvicorn, or Hypercorn) on an affected version (4.2 < 4.2.30, 5.2 < 5.2.13, 6.0 < 6.0.4).
2. Understand header trust: Analyze the application's authentication or access control logic to identify which HTTP headers are trusted (e.g., X-Forwarded-For for IP allowlisting, or a custom X-Auth-User header).
3. Craft ambiguous header: Send an HTTP request to the ASGI application that includes a header using underscores instead of hyphens (e.g., X_Forwarded_For: 127.0.0.1 instead of X-Forwarded-For: 127.0.0.1). Due to Django's normalization, both variants resolve to the same internal key.
4. Override trusted header: If a reverse proxy or upstream component sets a legitimate header (e.g., X-Forwarded-For), the attacker's underscore-variant header may conflict with or override it in Django's internal representation, allowing the attacker to supply a spoofed value.
5. Achieve bypass: The application reads the spoofed header value and grants access or elevated privileges based on the attacker-controlled data (e.g., bypassing IP restrictions or impersonating a trusted user).

• Network: Unusual HTTP requests to ASGI-served Django endpoints containing headers with underscores where hyphens are expected (e.g., X_Forwarded_For, X_Real_Ip, X_Auth_Token); requests from unexpected IP addresses that appear to originate from trusted ranges due to spoofed forwarding headers.
• Logs: Django application logs showing authentication successes or access grants from IP addresses inconsistent with actual client IPs; ASGI server access logs (Daphne/Uvicorn) recording requests with underscore-variant headers alongside standard hyphenated headers.
• Application Behavior: Unexpected privilege escalation events or access to restricted resources by users or IPs that should not have access; anomalous session activity correlated with requests containing non-standard header formatting.

Django has released patched versions addressing this vulnerability: 4.2.30, 5.2.13, and 6.0.4 (Django Blog, Django Security Releases). Users on unsupported series (5.0.x, 4.1.x, 3.2.x) should upgrade to a currently supported and patched version. As a workaround, review and harden application-level header validation logic to ensure it does not rely solely on header-based trust for authentication decisions, and consider implementing additional authentication mechanisms independent of HTTP headers. IBM Storage Defender - Resiliency Service users should refer to the IBM advisory for product-specific guidance (IBM Advisory).

The Django Software Foundation credited Tarek Nakkouch for responsible disclosure and published a security advisory and patched releases on April 7, 2026 (Django Blog). The vulnerability was discussed on the oss-security mailing list shortly after disclosure (oss-sec). Downstream Linux distributions including Ubuntu, openSUSE, SUSE, Fedora, and Mageia issued security advisories and updated packages in the days following disclosure. IBM also issued an advisory for affected IBM Storage Defender products (IBM Advisory). Community reaction has been measured, consistent with the moderate severity and lack of active exploitation.