Django CVE-2026-84429

Exploitation requires the Django application to invoke parse_header_parameters() on attacker-controlled input, which happens by default during content negotiation via HttpRequest.accepts() and when parsing Accept or Content-Type headers - no non-default configuration or feature toggle is needed. The attacker must craft a quoted parameter value containing many separator characters to trigger the quadratic parsing cost, and can use repeated headers to bypass the per-call length limit since it does not bound their combined size. Limiting factors: impact is partial availability only (A:L) with no data exposure; the application must actually reach this parsing path (content-negotiation or header-parameter handling), and the affected versions are Django 6.1<6.1.2, 6.0<6.0.9, and 5.2<5.2.18 (earlier unsupported series may also be affected but were not evaluated).

This is a moderate-severity, availability-only denial-of-service issue (CWE-407, inefficient algorithmic complexity). The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, base 5.3) indicates a network-reachable, low-complexity, unauthenticated attack with no user interaction - favorable conditions for an attacker - but the impact is limited to partial availability (A:L) with zero confidentiality or integrity effect, which caps real-world severity. Django itself rates this 'moderate' per its security policy, consistent with the quadratic (not exponential) parsing cost. No EPSS score was provided in the input, so exploitation probability cannot be quantified; there is no CISA KEV listing and no public exploit was identified at time of analysis, so there is no confirmed active exploitation. The one tension worth noting: the 'Information Disclosure' tag in the input conflicts with the actual vulnerability class - this is a pure availability DoS (C:N/I:N/A:L), not information disclosure, so that tag appears mislabeled. Net assessment: a legitimate patch-management priority for Django operators because it is unauthenticated and remotely reachable via standard headers, but it is not a drop-everything emergency given partial availability impact only and no evidence of exploitation.

An unauthenticated attacker sends an HTTP request to a Django application carrying a crafted Accept or Content-Type header (or repeated such headers) containing a quoted parameter value with a very large number of separator characters. When Django performs content negotiation via HttpRequest.accepts(), parse_header_parameters() parses this value with quadratic time complexity, consuming excessive CPU; because the per-call length limit does not bound the combined size of repeated headers, the attacker can amplify the cost and degrade or exhaust worker capacity. No public exploit code was identified at time of analysis.