Django REST Framework CVE-2026-114137

Exploitation requires that token revocation is performed by calling delete() on a TokenProxy instance (from applications, administrative integrations, or operational scripts) on DRF 3.12.0 through 3.18.1. Source-code test evidence indicates the silent zero-row deletion is reached on Django's deletion-collector slow path - for example when a model defines a cascading ForeignKey to Token, which pushes deletion onto the pk-matching path where the proxy's user-id pk fails to match the Token key primary key. Limiting factors: DRF's built-in TokenAdmin.delete_model is NOT affected because it maps back to the concrete Token, so sites that revoke only through the standard Django admin are safe; the attacker must already possess a previously issued token; and because DRF tokens never auto-expire, the exposure window is unbounded until manual database cleanup.

CVSS is 7.4 (High) with vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, but the practical risk profile is that of a credential-hygiene / failed-revocation defect (CWE-390), not a direct remote exploit. No EPSS score, no CISA KEV listing, and no public POC were provided in the input, so there is no public exploit identified at time of analysis and no evidence of active or widespread exploitation - signals are consistent rather than conflicting. The High CVSS is driven by C:H/I:H (a live API token grants read/write as the token's user), while AC:H correctly reflects that the silent-deletion path is not universally hit. A key nuance: the vector reports PR:N (unauthenticated), yet the realistic actor is someone who already holds a legitimately issued token that an operator attempted to revoke - the 'attack' is continued use of a credential that revocation silently failed to remove, so the PR:N labeling is technically per-vector but should not be read as 'anonymous remote code execution.' Real priority is moderate and situational: elevated for organizations that programmatically revoke tokens via TokenProxy.delete() (custom admin integrations, SSO/offboarding scripts) and negligible for those relying only on DRF's built-in TokenAdmin, which is unaffected.

After a DRF API token is known compromised or an employee is offboarded, an operational/admin script revokes it by calling delete() on a TokenProxy instance; the query matches zero rows and reports success, so the token silently remains live and continues authenticating to the API indefinitely. The attacker who retains that token keeps reading and writing API data as the victim user while administrators believe access was cut off. No public exploit code exists and exploitation is passive, relying on retention of a token that revocation failed to remove.