Description

An issue was discovered in Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18. `django.utils.http.parse_header_parameters()` was subject to a potential denial-of-service attack due to quadratic time complexity when parsing a value with many separators inside a quoted parameter. An unauthenticated request could reach this parsing through headers such as `Accept` or `Content-Type`, for instance via the content negotiation performed by `HttpRequest.accepts()`. The per-call length limit does not bound the combined size of repeated headers. Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected. Django would like to thank Jisung Chae for reporting this issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-10-06T14:17:46.910Z",
  "pubdate": "2026-10-06T14:17:46.910Z",
  "executiveSummary": "A quadratic time complexity vulnerability exists in django.utils.http.parse_header_parameters(), allowing for a Denial of Service (DoS) attack.\nThe vulnerability affects Django versions 6.1 prior to 6.1.2, 6.0 prior to 6.0.9, and 5.2 prior to 5.2.18, with potential exposure in unsupported versions including 5.1.x, 5.0.x, and 4.2.x.\nThe flaw stems from inefficient parsing logic when processing quoted parameters containing numerous separators within HTTP headers such as 'Accept' or 'Content-Type'.\nAn unauthenticated attacker can exploit this remotely by sending crafted HTTP requests designed to trigger excessive CPU consumption.\nBecause the per-call length limit does not account for the cumulative size of repeated headers, an attacker can induce resource exhaustion, leading to service unavailability.\nThe risk is significant as it requires no prior authentication or specific privileges, making it easily reachable via standard web traffic.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of django.utils.http.parse_header_parameters(), which exhibits O(n^2) quadratic time complexity when parsing header values that include quoted strings with a high density of separator characters.\nThe function is responsible for parsing complex HTTP header values. In scenarios where an attacker provides a crafted string containing a large number of internal separators within a quoted section, the parser's logic becomes computationally expensive relative to the input length.\nThe vulnerability is accessible to unauthenticated remote attackers through standard HTTP request headers, most notably the 'Accept' and 'Content-Type' headers. These headers are commonly processed by Django during request handling, specifically within the content negotiation process triggered by methods like HttpRequest.accepts().\nA critical aspect of this flaw is the insufficient bounding of inputs; while the system may enforce length limits on individual header values, these limits do not restrict the aggregate size of repeated headers or the complexity of the internal structures within a single header.\nExploitation involves an attacker crafting an HTTP request containing a header with a malicious, separator-heavy quoted parameter. Upon receiving this request, the Django framework invokes the vulnerable parsing function. Due to the quadratic time complexity of the algorithm, the CPU cycles required to parse the header grow exponentially with the number of separators.\nThis leads to an immediate CPU spike on the server processing the request. By sending multiple such requests concurrently or in sequence, an attacker can exhaust the server's thread pool or CPU resources, effectively causing a Denial of Service for legitimate users.\nThe impact is focused on availability. Since the parsing occurs early in the request lifecycle, even before substantial business logic is executed, the vulnerability is highly effective at disrupting services. The exploit requires no special privileges and operates over standard HTTP/HTTPS protocols, making it a viable target for automated tools or script-based attacks against exposed Django applications.\nUnsupported series such as 5.1.x, 5.0.x, and 4.2.x share similar architectural patterns and are suspected to be susceptible, as the underlying parsing logic has historically been consistent across these versions."
}