CVE-2026-84429: Django parse_header_parameters DoS Vulnerability

CVE-2026-84429 Overview

CVE-2026-84429 is a denial-of-service vulnerability affecting the Django web framework. The flaw resides in django.utils.http.parse_header_parameters(), which exhibits quadratic time complexity when parsing values containing many separators inside a quoted parameter. An unauthenticated attacker can trigger expensive parsing by sending crafted HTTP headers such as Accept or Content-Type, which Django processes through content negotiation in HttpRequest.accepts(). The per-call length limit does not bound the combined size of repeated headers, allowing amplification. The vulnerability is tracked under CWE-407: Inefficient Algorithmic Complexity.

Critical Impact
Unauthenticated remote attackers can exhaust CPU resources on Django application servers through crafted HTTP headers, degrading availability for legitimate users.

Affected Products

Django 6.1 before 6.1.2
Django 6.0 before 6.0.9
Django 5.2 before 5.2.18
Earlier unsupported series (5.1.x, 5.0.x, 4.2.x) were not evaluated and may also be affected

Discovery Timeline

Vulnerability reported by Jisung Chae to the Django security team
2026-10-06 - CVE-2026-84429 published to NVD and Django security releases issued
2026-10-06 - Last updated in NVD database

Technical Details for CVE-2026-84429

Vulnerability Analysis

The vulnerability is an algorithmic complexity attack against Django's HTTP header parser. parse_header_parameters() processes header values that follow the RFC 7231 parameter syntax, such as text/html; charset=utf-8. When parsing a quoted parameter containing many separator characters, the function's logic degenerates to quadratic time, meaning doubling the input length quadruples the CPU time required.

Because the parser is reached through standard content negotiation via HttpRequest.accepts(), any public-facing Django endpoint that inspects request headers is a candidate target. No authentication is required, and the attacker does not need a valid session or route to a specific view.

The amplification is compounded by HTTP header handling: although a single call enforces a length limit, the combined size of repeated headers across one request is not bounded, enabling attackers to force many expensive parses per request.

Root Cause

The root cause is the hand-rolled parsing logic in django.utils.http.parse_header_parameters(), which performs repeated substring operations across a quoted parameter containing numerous separator characters. The upstream fix replaces this logic with Python's standard library email.message.Message-based parser.

Attack Vector

An unauthenticated attacker sends an HTTP request to any Django endpoint reachable over the network. The request includes malicious Accept or Content-Type headers crafted with long quoted parameter values containing many separators. Repeating the vulnerable header multiplies the parsing cost. Each request can consume significant CPU time on the application server.

python

# Upstream fix in django/utils/http.py: replace custom parser with stdlib
 import base64
+import codecs
 import re
 import unicodedata
 from binascii import Error as BinasciiError
 from datetime import UTC, datetime
-from email.utils import formatdate
-from urllib.parse import quote, unquote
+from email.message import Message
+from email.utils import collapse_rfc2231_value, formatdate
+from urllib.parse import quote
 from urllib.parse import urlencode as original_urlencode
 from urllib.parse import urlsplit

Source: Django Commit 7ff7fcc. The patch removes the custom tokenization and delegates parsing to email.message.Message, eliminating the quadratic behavior.

Detection Methods for CVE-2026-84429

Indicators of Compromise

Inbound HTTP requests with unusually long Accept or Content-Type headers, often several kilobytes in size
Quoted parameter values containing dense sequences of separator characters such as semicolons, commas, or equals signs
Requests that include many repeated instances of the same header name to bypass per-call length limits
Sustained CPU saturation on Django worker processes without a corresponding increase in request volume

Detection Strategies

Inspect reverse-proxy or WAF logs for requests whose header size approaches or exceeds configured limits
Correlate spikes in request latency with specific client source IPs sending oversized Accept or Content-Type headers
Enable Python-level profiling or APM instrumentation on django.utils.http.parse_header_parameters to identify abnormal time spent in that function

Monitoring Recommendations

Alert on sustained worker CPU above baseline when request-per-second volume remains flat
Track p95 and p99 request latency by endpoint and alert on sudden regressions
Log the size and count of inbound request headers at the edge for post-incident analysis

How to Mitigate CVE-2026-84429

Immediate Actions Required

Upgrade to Django 6.1.2, 6.0.9, or 5.2.18 depending on the deployed series
If running an unsupported series such as 5.1.x, 5.0.x, or 4.2.x, migrate to a supported, patched release because those branches were not evaluated
Apply rate limiting and header-size limits at the reverse proxy or WAF to reduce exposure until patching completes

Patch Information

The Django project released fixed versions on 2026-10-06. The relevant commits are 3d8f121 for the 6.0.x branch, 6ecd66e for the 5.2.x branch, and 7ff7fcc on main. See the Django Security Releases Blog and Django Security Release Notes for details. Note that parsing of some malformed or unusual header values may differ after the fix because the implementation now uses email.message.Message; for example, RFC 2231 values with a missing encoding are now decoded.

Workarounds

Enforce strict maximum header size and header count at the reverse proxy (for example, Nginx large_client_header_buffers or client_header_buffer_size)
Deploy WAF rules that drop requests containing abnormally long Accept or Content-Type values or high counts of repeated header names
Apply per-IP rate limiting on public endpoints to blunt sustained parsing attacks until patches are deployed

bash

# Upgrade Django to a patched release
pip install --upgrade "Django==6.1.2"   # 6.1.x branch
pip install --upgrade "Django==6.0.9"   # 6.0.x branch
pip install --upgrade "Django==5.2.18"  # 5.2.x LTS branch

# Example Nginx header hardening (place in http or server block)
# client_header_buffer_size 1k;
# large_client_header_buffers 4 8k;
# limit_req_zone $binary_remote_addr zone=django_rl:10m rate=20r/s;