CVE-2026-114137

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 leave access available indefinitely because DRF tokens do not expire automatically. This issue is fixed in version 3.18.2.

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 leave access available indefinitely because DRF tokens do not expire automatically. This issue is fixed in version 3.18.2.

Summary

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 (rest_framework/authtoken/models.py:49-63):

@property
def pk(self):
    return self.user_id

The concrete Token model keys on key, not on an integer id. Model.delete() builds its delete query from pk, so it emits:

DELETE FROM "authtoken_token" WHERE "authtoken_token"."key" IN ('1')

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 rest_framework/authtoken/admin.py, TokenAdmin.delete_model re-fetches the concrete row:

def delete_model(self, request, obj):
    Token.objects.get(key=obj.key).delete()   # admin.py:30

and TokenAdmin sets actions = None with the comment "Actions not compatible with mapped IDs" (admin.py:50-53). The shipped admin path is therefore safe, and every other caller of TokenProxy.delete() is not. Nothing in the API signals the difference.

TokenProxy was added by e2bd3b6a (PR #7341, "Adjusted token admin to map to user ID"), first released in 3.12.0.

A fix would drop the pk override, or give TokenProxy a delete() that operates on the concrete row, or raise instead of silently reporting zero deletions.

PoC

Save as poc_tokenproxy_revocation.py and run it.

#!/usr/bin/env python
"""
django-rest-framework: TokenProxy.delete() reports success and revokes nothing.

  baseline  token exists                        -> 200
  TRIGGER   TokenProxy.objects.get(...).delete() -> no exception, row survives, still 200
  CONTROL   Token.objects.get(key=...).delete()  -> row gone, 401

The control is what makes the trigger meaningful: it proves the row was
deletable and the credential check live, so the 200 after the proxy delete is a
failed revocation and not a broken harness.

Requires: django, djangorestframework importable. No arguments.
    python poc_tokenproxy_revocation.py
Exit status 0 means the revocation failure reproduced.
"""
import sys

import django
from django.conf import settings

settings.configure(
    DEBUG=False,
    SECRET_KEY="poc",
    ALLOWED_HOSTS=["*"],
    ROOT_URLCONF=__name__,
    INSTALLED_APPS=[
        "django.contrib.contenttypes",
        "django.contrib.auth",
        "rest_framework",
        "rest_framework.authtoken",
    ],
    DATABASES={"default": {"ENGINE": "django.db.backends.sqlite3", "NAME": ":memory:"}},
    DEFAULT_AUTO_FIELD="django.db.models.AutoField",
    USE_TZ=True,
)
django.setup()

from django.contrib.auth import get_user_model  # noqa: E402
from django.core.management import call_command  # noqa: E402
from django.db import connection  # noqa: E402
from django.test import Client  # noqa: E402
from django.test.utils import CaptureQueriesContext  # noqa: E402
from django.urls import path  # noqa: E402

from rest_framework.authentication import TokenAuthentication  # noqa: E402
from rest_framework.authtoken.models import Token, TokenProxy  # noqa: E402
from rest_framework.permissions import IsAuthenticated  # noqa: E402
from rest_framework.response import Response  # noqa: E402
from rest_framework.views import APIView  # noqa: E402


class Whoami(APIView):
    authentication_classes = [TokenAuthentication]
    permission_classes = [IsAuthenticated]

    def get(self, request):
        return Response({"user": request.user.get_username()})


urlpatterns = [path("", Whoami.as_view())]


def probe(client, key):
    response = client.get("/",…

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 leave access available indefinitely because DRF tokens do not expire automatically. This issue is fixed in version 3.18.2.

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 leave access available indefinitely because DRF tokens do not expire automatically. This issue is fixed in version 3.18.2.

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 leave access available indefinitely because DRF tokens do not expire automatically. This issue is fixed in version 3.18.2.