<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-22T22:56:58.008616+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-114137</id>
    <title>fkie_cve-2026-114137</title>
    <updated>2026-10-22T22:56:58.009871+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-114137"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-xw6w-gcfp-cf8m</id>
    <title>GHSA-xw6w-gcfp-cf8m — Django REST framework: TokenProxy.delete() reports success and revokes nothing</title>
    <updated>2026-10-22T22:56:58.009957+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: djangorestframework</p>
<p>### Summary</p>
<p>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.</p>
<p>### Details</p>
<p>`TokenProxy` overrides `pk` to return the user id (`rest_framework/authtoken/models.py:49-63`):</p>
<p>```python
@property
def pk(self):
    return self.user_id
```</p>
<p>The concrete `Token` model keys on `key`, not on an integer id. `Model.delete()` builds its delete
query from `pk`, so it emits:</p>
<p>```sql
DELETE FROM "authtoken_token" WHERE "authtoken_token"."key" IN ('1')
```</p>
<p>That matches a user id against the 40-character key column. Nothing matches, nothing raises, and the
call returns `(0, {'authtoken.TokenProxy': 0})`.</p>
<p>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:</p>
<p>```python
def delete_model(self, request, obj):
    Token.objects.get(key=obj.key).delete()   # admin.py:30
```</p>
<p>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.</p>
<p>`TokenProxy` was adde…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-xw6w-gcfp-cf8m"/>
  </entry>
</feed>
