CVE-2026-114137 in Django REST Framework
Summary
by MITRE • 10/21/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
Django REST framework serves as a robust toolkit for constructing Web APIs within the Django ecosystem, providing essential components for serialization, authentication, and permission handling. A critical security flaw was identified in the TokenProxy class located within the rest_framework/authtoken/models.py module, affecting versions from 3.12.0 through 3.18.2. This vulnerability stems from a fundamental mismatch between the primary key used by the proxy model and the actual database row identifier for authentication tokens. Specifically, when an application attempts to revoke credentials by calling TokenProxy.delete(), the method incorrectly utilizes the user-id primary key associated with the proxy instance rather than the concrete token-string primary key that uniquely identifies rows in the underlying database table.
The technical consequence of this implementation error is that Django generates a deletion query targeting the wrong identifier, resulting in zero rows being affected and no exception being raised to alert the caller of the failure. This silent failure creates a dangerous state where administrative integrations or operational scripts believe that credential revocation has been successfully executed. In reality, the authentication token remains active in the database and continues to function for subsequent API requests. Since Django REST Framework tokens do not possess an automatic expiration mechanism by default, this oversight allows potentially compromised credentials to remain valid indefinitely unless manually corrected through direct database intervention or other administrative means.
The operational impact of this vulnerability is significant for any system relying on automated credential lifecycle management. Security teams and developers who integrate token revocation into their workflows may operate under the false assumption that a revoked user no longer has access, leading to prolonged exposure in the event of a breach. While DRF's internal TokenAdmin.delete_model workaround correctly handles deletion by targeting the proper primary key and remains unaffected, external callers using standard proxy methods are left vulnerable. This discrepancy highlights a gap between framework-internal best practices and public API usage patterns that can lead to persistent unauthorized access if not properly addressed in application logic or patched via an upgrade.
To mitigate this risk, organizations running affected versions must immediately upgrade Django REST Framework to version 3.18.2 or later, where the TokenProxy.delete() method has been corrected to use the appropriate primary key for deletion operations. For systems that cannot be upgraded instantly, developers should implement manual verification steps after attempting to delete a token via the proxy, such as querying the database directly to confirm the row count is zero and raising an error if it is not. Additionally, implementing periodic audits of active tokens against revoked user lists can help detect lingering access resulting from this flaw. This issue aligns with CWE-253, which describes incorrect check for condition, specifically where a failure in validation or state change does not result in the expected security outcome due to improper identifier usage. From an ATT&CK perspective, this vulnerability facilitates Persistence techniques by allowing attackers who have obtained valid tokens to maintain access even after attempted revocation efforts, undermining incident response procedures that rely on credential invalidation as a containment strategy.