Django REST Framework CVE-2026-114138

No authentication or user interaction is required (PR:N/UI:N): any reachable DRF endpoint that performs content negotiation is exploitable by sending an Accept header with an unbounded number and aggregate size of media-type tokens containing large quoted parameter values and many semicolons (the Content-Type header is a secondary vector, now length-capped in the fix). The condition is inherent to default DRF content negotiation, so no non-default feature flag is needed. The main LIMITING factors on real-world impact are: (1) deployment on synchronous worker models (e.g. gunicorn sync workers / WSGI) amplifies worker pinning, whereas async or heavily autoscaled/rate-limited front-ends blunt it; (2) impact is availability-only and self-healing once requests cease; and (3) an upstream reverse proxy or WAF that caps Accept/Content-Type header length can neutralize the oversized-header vector before it reaches Django.

All signals align on this being a genuine but bounded availability risk rather than a top-tier emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) is internally consistent with the description: a remote, unauthenticated attacker over the network, with low complexity and no user interaction, achieves a pure availability impact (C:N/I:N) via CPU exhaustion - a textbook CWE-400 algorithmic/resource-consumption DoS. No EPSS score, KEV listing, POC, or SSVC decision data was supplied in the input, so no public exploit identified at time of analysis and there is no evidence of active exploitation. The practical risk is tempered by the impact ceiling: this cannot read data, alter data, or achieve code execution - worst case is worker starvation and service unavailability that ends once the malicious requests stop. It is a real patching priority for any internet-exposed DRF API running synchronous workers (because a few concurrent crafted requests can pin them), but it is not a 'drop everything' critical like an RCE. The absence of KEV/EPSS/POC data means exploitation likelihood is inferred only from the low attack complexity and the public fix commit, not confirmed; a well-documented patch commit does raise the chance that a reproduction will be derived from the diff.

An attacker scripts HTTP requests to any reachable DRF endpoint, each carrying an Accept header packed with many distinct media types whose quoted parameter values contain large strings and numerous semicolons. Because DRF re-parses every attacker-controlled token against every renderer (and again during forced 406 renegotiation), each request consumes disproportionate CPU; firing these concurrently pins the synchronous worker pool and renders the API unavailable. No proof-of-concept was provided in the input, but the public fix commit reveals the exact parsing hotspots an attacker could target.