p PatchFirst

PatchFirst · Latest vulnerabilities

djangorestframework vulnerabilities

Vulnerabilities published for djangorestframework in the last 30 days: 3. Listed in the KEV catalogue: 0.

RSS ↗
Filter vulnerabilities
Clear filters

Vulnerabilities: 7

  1. CVE-2026-114138

    High · CVSS 7.5EPSS 0.43%Public exploitFix available

    Django REST framework: Accept header with many large quoted parameters burns ~19s of CPU per request in content negotiation

    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's parameter parser and DRF's repeated parsing structure to consume disproportionate CPU. Re

    djangorestframeworkPython
    • Update to 3.18.2
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  2. CVE-2026-114137

    High · CVSS 7.4EPSS 0.35%Public exploitFix available

    Django REST framework: TokenProxy.delete() reports success and revokes nothing

    Django REST framework is a toolkit for building Web APIs. From 3.12.0 until 3.18.2, TokenProxy.delete() in rest_framework/authtoken/models.py uses the proxy's user-id pk while the concrete Token token-string primary key identifies rows, so Django issues a deletion query that matches no row and reports zero deletions without raising an error. Applications, administrative integrations, or operational scripts that revoke credentials through a TokenProxy instance can therefore believe revocation succeeded while the token remains live and continues authenticating. DRF's own TokenAdmin.delete_model workaround is not affected, but other callers can

    djangorestframeworkPython
    • Update to 3.18.2
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  3. CVE-2026-114136

    High · CVSS 7.5EPSS 0.34%Public exploitFix available

    Django REST framework: JSONParser applies an attacker-named codec to the request stream

    Django REST framework is a toolkit for building Web APIs. From 3.6.4 until 3.18.2, JSONParser.parse in rest_framework/parsers.py uses the client-supplied Content-Type charset value with codecs.getreader, which accepts byte-transform codecs such as bz2_codec rather than only text encodings. A remote unauthenticated client can therefore cause a compressed JSON request body to be expanded after Django has enforced DATA_UPLOAD_MAX_MEMORY_SIZE against only the wire bytes, allowing a very small request to consume substantial per-worker memory. The default parser set is sufficient, and any reachable endpoint that accepts a JSON body is affected. Thi

    djangorestframeworkPython
    • Update to 3.18.2
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  4. CVE-2026-73229

    Medium · CVSS 4.3EPSS 0.37%Fix available

    Django REST framework: AdminRenderer may disclose GET-protected data when rendering invalid write requests

    Django REST framework is a powerful and flexible toolkit for building Web APIs. Prior to 3.17.2, Django REST Framework's rest_framework/renderers.py AdminRenderer.render() uses override_method() to simulate GET and directly invokes view.get() without view.check_permissions() while rendering an invalid write request, allowing a 400 Bad Request HTML response to disclose data from a GET representation that the requester is not permitted to access. This issue is fixed in version 3.17.2.

    djangorestframeworkPython
    • Update to 3.17.2
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  5. CVE-2026-73228

    Medium · CVSS 5.3EPSS 0.56%Fix available

    Django REST framework: Potential bypass of Django `DATA_UPLOAD_MAX_MEMORY_SIZE` when parsing oversized JSON and urlencoded request bodies via DRF `request.data`

    Django REST framework is a toolkit for building Web APIs. Prior to 3.17.2, Django REST Framework's request.data parsing in rest_framework/request.py Request._parse() passes the underlying HttpRequest stream to JSONParser and FormParser for application/json and application/x-www-form-urlencoded bodies, bypassing Django's DATA_UPLOAD_MAX_MEMORY_SIZE protection and allowing oversized request bodies to consume additional memory and CPU. This issue is fixed in version 3.17.2.

    djangorestframeworkPython
    • Update to 3.17.2
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  7. CVE-2020-25626

    Medium · CVSS 6.1EPSS 1.3%Fix available

    CVE-2020-25626

    A flaw was found in Django REST Framework versions before 3.12.0 and before 3.11.2. When using the browseable API viewer, Django REST Framework fails to properly escape certain strings that can come from user input. This allows a user who can control those strings to inject malicious <script> tags, leading to a cross-site-scripting (XSS) vulnerability.

    djangorestframeworkPython
    • Update to 3.11.2
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

Check your server

Check your installed stack and versions against the current vulnerability feeds.

Check your server →