Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Deleting an authentication token through TokenProxy silently deletes nothing. The call raises no exception and reports success, the database row survives, and the token keeps authenticating. Any application, admin integration or operational script that revokes credentials by calling .delete() on a TokenProxy instance believes it has revoked a token that is still live. Details TokenProxy overrides pk to return the user id (restframework/authtoken/models.py:49-63): The concrete Token model keys on key, not on an integer id. Model.delete() builds its delete query from pk, so it emits: That matches a user id against the 40-character key column. Nothing matches, nothing raises, and the call returns (0, {'authtoken.TokenProxy': 0}). DRF already ships two workarounds for this same identity mismatch instead of a fix. In restframework/authtoken/admin.py, TokenAdmin.deletemodel re-fetches the concrete row: and TokenAdmin sets actions = None with the comment "Actions not compatible with…
Recommended action: Upgrade to 3.18.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
DRF's 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's parseheaderparameters, 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's 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. Details What happens getacceptlist() splits the Accept header on commas with no cap on token count or total size, at restframework/negotiation.py:96-97. For every token, selectrenderer() calls…
Recommended action: Upgrade to 3.18.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An unauthenticated attacker can defeat Django's DATAUPLOADMAXMEMORYSIZE limit and force a worker process to allocate arbitrary memory, by naming a compression codec in the Content-Type charset parameter. A 108-byte request body produces a 50,331,648-character value inside the view, an amplification factor of 466,033, and grows process peak RSS by about 97 MiB. No application configuration is required beyond DRF's default parser set; the endpoint only has to accept a JSON body. Details JSONParser.parse decodes the request body with the charset the client supplied on the Content-Type header: Of the roughly 455 codec names codecs.lookup resolves on CPython 3.14, about 18 are byte transforms instead of character sets: bz2codec, zlibcodec, base64codec, hexcodec, quopricodec, uucodec and similar. codecs.getreader is the only entry point in the codecs module that does not consult CodecInfo.istextencoding, so it accepts all of them. Sending Content-Type: application/json;…
Recommended action: Upgrade to 3.18.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
While investigating Django REST Framework's request parsing behavior, I identified that DRF's high-level request.data parsing appears to bypass Django's configured DATAUPLOADMAXMEMORYSIZE protection for application/json and application/x-www-form-urlencoded request bodies. In the tested configurations, Django correctly raises RequestDataTooBig when applications access request.body or Django's native request.POST, but DRF successfully parses the same oversized payloads through request.data. This behavior appears to occur because DRF passes the underlying HttpRequest object directly to parsers, which consume the request stream through Django's lower-level streaming interface rather than the guarded request.body path. I am reporting this privately because I am unsure whether this behavior is considered part of DRF's intended security boundary, but it appears to bypass a documented Django request-size protection for common DRF request parsing paths and may have availability…
Recommended action: Upgrade to 3.17.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
AdminRenderer may disclose data that would normally be protected by GET permissions when rendering a 400 Bad Request response for an invalid write request. If a view allows POST (or another write method) but denies GET, an invalid request rendered through AdminRenderer can invoke the view's GET handler and include data from the GET representation in the generated HTML response. This behavior appears to be specific to AdminRenderer and does not affect the normal JSON rendering path. --- Details While investigating the AdminRenderer rendering flow, I observed that invalid write requests are rendered by temporarily overriding the request method and invoking the view's GET handler: This execution path differs from a normal GET request. Under normal request processing, a GET request flows through: However, during AdminRenderer rendering, the renderer directly invokes: view.get(...) A view whose permission class explicitly allowed POST but denied GET still executed its GET handler…
Recommended action: Upgrade to 3.17.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of the package djangorestframework before 3.15.2 are vulnerable to Cross-site Scripting (XSS) via the breaklongheaders template filter due to improper input sanitization before splitting and joining with <br tags.
Recommended action: Upgrade to 3.15.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.11.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.