CVE-2026-114137

### 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`): ```python @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: ```sql 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: ```python 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. ```python #!/usr/bin/env python """ django-rest-framework: TokenProxy.delete() reports success and revokes nothing. baseline token exists -> 200 TRIGGER