Vulnerability-Lookup

GHSA-XW6W-GCFP-CF8M

Vulnerability from github – Published: 2026-10-22 16:18 – Updated: 2026-10-22 16:18

Summary

Django REST framework: TokenProxy.delete() reports success and revokes nothing

Details

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("/", headers={"authorization": "Token %s" % key})
    return response.status_code


def main():
    call_command("migrate", run_syncdb=True, verbosity=0)
    user = get_user_model().objects.create_user(username="revoke-user", password="pw")
    key = Token.objects.create(user=user).key
    client = Client()

    print("TokenProxy._meta.proxy   =", TokenProxy._meta.proxy)
    print("Token._meta.pk.attname   =", Token._meta.pk.attname)
    print("user.pk                  =", user.pk)
    print("token key                =", key)

    print("\n--- baseline")
    print("rows                     =", Token.objects.count())
    baseline = probe(client, key)
    print("GET / with token         ->", baseline)

    print("\n--- TRIGGER: delete through the proxy")
    proxy = TokenProxy.objects.get(user=user)
    print("proxy.pk                 =", proxy.pk, "(TokenProxy.pk property)")
    raised = None
    with CaptureQueriesContext(connection) as ctx:
        try:
            returned = proxy.delete()
        except Exception as exc:  # noqa: BLE001
            raised, returned = exc, None
    for q in ctx.captured_queries:
        if "DELETE" in q["sql"]:
            print("    SQL:", q["sql"])
    print("raised                   =", repr(raised))
    print("returned                 =", returned)
    print("rows                     =", Token.objects.count())
    after_proxy = probe(client, key)
    print("GET / with token         ->", after_proxy)

    print("\n--- CONTROL: delete the same row through the concrete model")
    with CaptureQueriesContext(connection) as ctx2:
        returned2 = Token.objects.get(key=key).delete()
    for q in ctx2.captured_queries:
        if "DELETE" in q["sql"]:
            print("    SQL:", q["sql"])
    print("returned                 =", returned2)
    print("rows                     =", Token.objects.count())
    after_real = probe(client, key)
    print("GET / with token         ->", after_real)

    ok = baseline == 200 and raised is None and after_proxy == 200 and after_real == 401
    print(
        "\nrevocation failure reproduced:", ok,
        "(baseline 200, still 200 after proxy delete, 401 after real delete)",
    )
    return 0 if ok else 1


if __name__ == "__main__":
    sys.exit(main())

Observed output:

TokenProxy._meta.proxy   = True
Token._meta.pk.attname   = key
user.pk                  = 1
token key                = 6a644878f252175d39205804c5a6faf16df67c10

--- baseline
rows                     = 1
GET / with token         -> 200

--- TRIGGER: delete through the proxy
proxy.pk                 = 1 (TokenProxy.pk property)
    SQL: DELETE FROM "authtoken_token" WHERE "authtoken_token"."key" IN ('1')
raised                   = None
returned                 = (0, {'authtoken.TokenProxy': 0})
rows                     = 1
GET / with token         -> 200

--- CONTROL: delete the same row through the concrete model
    SQL: DELETE FROM "authtoken_token" WHERE "authtoken_token"."key" IN ('6a644878...')
returned                 = (1, {'authtoken.Token': 1})
rows                     = 0
GET / with token         -> 401

revocation failure reproduced: True

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. Reproduced identically on Django 6.1 and 5.2.17 LTS, so this is not a recent Django regression.

Impact

Failed credential revocation. An operator who revokes a token through a TokenProxy instance, and receives no error, leaves a live credential in circulation indefinitely, because DRF auth tokens do not expire on their own. Whoever holds that token benefits: a departed employee, a rotated integration, a device believed to be deprovisioned, or an attacker whose access was thought to have been cut during incident response.

No untrusted input reaches this code path, which is why the vector is scored AC:H. Exploitation depends on the deployment revoking through the proxy, which is a natural thing to do given TokenProxy is the model registered in the admin and the one most code will reach for. Any deployment on 3.12.0 or later that revokes tokens outside DRF's own TokenAdmin.delete_model should audit whether its revocations took effect.

Severity

7.4 (High)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "djangorestframework"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.12.0"
            },
            {
              "fixed": "3.18.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-114137"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-390",
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-22T16:18:05Z",
    "nvd_published_at": "2026-10-21T21:17:56Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nDeleting an authentication token through `TokenProxy` silently deletes nothing. The call raises no\nexception and reports success, the database row survives, and the token keeps authenticating. Any\napplication, admin integration or operational script that revokes credentials by calling `.delete()`\non a `TokenProxy` instance believes it has revoked a token that is still live.\n\n### Details\n\n`TokenProxy` overrides `pk` to return the user id (`rest_framework/authtoken/models.py:49-63`):\n\n```python\n@property\ndef pk(self):\n    return self.user_id\n```\n\nThe concrete `Token` model keys on `key`, not on an integer id. `Model.delete()` builds its delete\nquery from `pk`, so it emits:\n\n```sql\nDELETE FROM \"authtoken_token\" WHERE \"authtoken_token\".\"key\" IN (\u00271\u0027)\n```\n\nThat matches a user id against the 40-character key column. Nothing matches, nothing raises, and the\ncall returns `(0, {\u0027authtoken.TokenProxy\u0027: 0})`.\n\nDRF already ships two workarounds for this same identity mismatch instead of a fix. In\n`rest_framework/authtoken/admin.py`, `TokenAdmin.delete_model` re-fetches the concrete row:\n\n```python\ndef delete_model(self, request, obj):\n    Token.objects.get(key=obj.key).delete()   # admin.py:30\n```\n\nand `TokenAdmin` sets `actions = None` with the comment \"Actions not compatible with mapped IDs\"\n(`admin.py:50-53`). The shipped admin path is therefore safe, and every other caller of\n`TokenProxy.delete()` is not. Nothing in the API signals the difference.\n\n`TokenProxy` was added by `e2bd3b6a` (PR #7341, \"Adjusted token admin to map to user ID\"), first\nreleased in 3.12.0.\n\nA fix would drop the `pk` override, or give `TokenProxy` a `delete()` that operates on the concrete\nrow, or raise instead of silently reporting zero deletions.\n\n### PoC\n\nSave as `poc_tokenproxy_revocation.py` and run it.\n\n```python\n#!/usr/bin/env python\n\"\"\"\ndjango-rest-framework: TokenProxy.delete() reports success and revokes nothing.\n\n  baseline  token exists                        -\u003e 200\n  TRIGGER   TokenProxy.objects.get(...).delete() -\u003e no exception, row survives, still 200\n  CONTROL   Token.objects.get(key=...).delete()  -\u003e row gone, 401\n\nThe control is what makes the trigger meaningful: it proves the row was\ndeletable and the credential check live, so the 200 after the proxy delete is a\nfailed revocation and not a broken harness.\n\nRequires: django, djangorestframework importable. No arguments.\n    python poc_tokenproxy_revocation.py\nExit status 0 means the revocation failure reproduced.\n\"\"\"\nimport sys\n\nimport django\nfrom django.conf import settings\n\nsettings.configure(\n    DEBUG=False,\n    SECRET_KEY=\"poc\",\n    ALLOWED_HOSTS=[\"*\"],\n    ROOT_URLCONF=__name__,\n    INSTALLED_APPS=[\n        \"django.contrib.contenttypes\",\n        \"django.contrib.auth\",\n        \"rest_framework\",\n        \"rest_framework.authtoken\",\n    ],\n    DATABASES={\"default\": {\"ENGINE\": \"django.db.backends.sqlite3\", \"NAME\": \":memory:\"}},\n    DEFAULT_AUTO_FIELD=\"django.db.models.AutoField\",\n    USE_TZ=True,\n)\ndjango.setup()\n\nfrom django.contrib.auth import get_user_model  # noqa: E402\nfrom django.core.management import call_command  # noqa: E402\nfrom django.db import connection  # noqa: E402\nfrom django.test import Client  # noqa: E402\nfrom django.test.utils import CaptureQueriesContext  # noqa: E402\nfrom django.urls import path  # noqa: E402\n\nfrom rest_framework.authentication import TokenAuthentication  # noqa: E402\nfrom rest_framework.authtoken.models import Token, TokenProxy  # noqa: E402\nfrom rest_framework.permissions import IsAuthenticated  # noqa: E402\nfrom rest_framework.response import Response  # noqa: E402\nfrom rest_framework.views import APIView  # noqa: E402\n\n\nclass Whoami(APIView):\n    authentication_classes = [TokenAuthentication]\n    permission_classes = [IsAuthenticated]\n\n    def get(self, request):\n        return Response({\"user\": request.user.get_username()})\n\n\nurlpatterns = [path(\"\", Whoami.as_view())]\n\n\ndef probe(client, key):\n    response = client.get(\"/\", headers={\"authorization\": \"Token %s\" % key})\n    return response.status_code\n\n\ndef main():\n    call_command(\"migrate\", run_syncdb=True, verbosity=0)\n    user = get_user_model().objects.create_user(username=\"revoke-user\", password=\"pw\")\n    key = Token.objects.create(user=user).key\n    client = Client()\n\n    print(\"TokenProxy._meta.proxy   =\", TokenProxy._meta.proxy)\n    print(\"Token._meta.pk.attname   =\", Token._meta.pk.attname)\n    print(\"user.pk                  =\", user.pk)\n    print(\"token key                =\", key)\n\n    print(\"\\n--- baseline\")\n    print(\"rows                     =\", Token.objects.count())\n    baseline = probe(client, key)\n    print(\"GET / with token         -\u003e\", baseline)\n\n    print(\"\\n--- TRIGGER: delete through the proxy\")\n    proxy = TokenProxy.objects.get(user=user)\n    print(\"proxy.pk                 =\", proxy.pk, \"(TokenProxy.pk property)\")\n    raised = None\n    with CaptureQueriesContext(connection) as ctx:\n        try:\n            returned = proxy.delete()\n        except Exception as exc:  # noqa: BLE001\n            raised, returned = exc, None\n    for q in ctx.captured_queries:\n        if \"DELETE\" in q[\"sql\"]:\n            print(\"    SQL:\", q[\"sql\"])\n    print(\"raised                   =\", repr(raised))\n    print(\"returned                 =\", returned)\n    print(\"rows                     =\", Token.objects.count())\n    after_proxy = probe(client, key)\n    print(\"GET / with token         -\u003e\", after_proxy)\n\n    print(\"\\n--- CONTROL: delete the same row through the concrete model\")\n    with CaptureQueriesContext(connection) as ctx2:\n        returned2 = Token.objects.get(key=key).delete()\n    for q in ctx2.captured_queries:\n        if \"DELETE\" in q[\"sql\"]:\n            print(\"    SQL:\", q[\"sql\"])\n    print(\"returned                 =\", returned2)\n    print(\"rows                     =\", Token.objects.count())\n    after_real = probe(client, key)\n    print(\"GET / with token         -\u003e\", after_real)\n\n    ok = baseline == 200 and raised is None and after_proxy == 200 and after_real == 401\n    print(\n        \"\\nrevocation failure reproduced:\", ok,\n        \"(baseline 200, still 200 after proxy delete, 401 after real delete)\",\n    )\n    return 0 if ok else 1\n\n\nif __name__ == \"__main__\":\n    sys.exit(main())\n```\n\nObserved output:\n\n```\nTokenProxy._meta.proxy   = True\nToken._meta.pk.attname   = key\nuser.pk                  = 1\ntoken key                = 6a644878f252175d39205804c5a6faf16df67c10\n\n--- baseline\nrows                     = 1\nGET / with token         -\u003e 200\n\n--- TRIGGER: delete through the proxy\nproxy.pk                 = 1 (TokenProxy.pk property)\n    SQL: DELETE FROM \"authtoken_token\" WHERE \"authtoken_token\".\"key\" IN (\u00271\u0027)\nraised                   = None\nreturned                 = (0, {\u0027authtoken.TokenProxy\u0027: 0})\nrows                     = 1\nGET / with token         -\u003e 200\n\n--- CONTROL: delete the same row through the concrete model\n    SQL: DELETE FROM \"authtoken_token\" WHERE \"authtoken_token\".\"key\" IN (\u00276a644878...\u0027)\nreturned                 = (1, {\u0027authtoken.Token\u0027: 1})\nrows                     = 0\nGET / with token         -\u003e 401\n\nrevocation failure reproduced: True\n```\n\nThe control is what makes the trigger meaningful: it proves the row was deletable and the credential\ncheck live, so the 200 after the proxy delete is a failed revocation and not a broken harness.\nReproduced identically on Django 6.1 and 5.2.17 LTS, so this is not a recent Django regression.\n\n### Impact\n\nFailed credential revocation. An operator who revokes a token through a `TokenProxy` instance, and\nreceives no error, leaves a live credential in circulation indefinitely, because DRF auth tokens do\nnot expire on their own. Whoever holds that token benefits: a departed employee, a rotated\nintegration, a device believed to be deprovisioned, or an attacker whose access was thought to have\nbeen cut during incident response.\n\nNo untrusted input reaches this code path, which is why the vector is scored `AC:H`. Exploitation\ndepends on the deployment revoking through the proxy, which is a natural thing to do given\n`TokenProxy` is the model registered in the admin and the one most code will reach for. Any\ndeployment on 3.12.0 or later that revokes tokens outside DRF\u0027s own `TokenAdmin.delete_model` should\naudit whether its revocations took effect.",
  "id": "GHSA-xw6w-gcfp-cf8m",
  "modified": "2026-10-22T16:18:05Z",
  "published": "2026-10-22T16:18:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/encode/django-rest-framework/security/advisories/GHSA-xw6w-gcfp-cf8m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-114137"
    },
    {
      "type": "WEB",
      "url": "https://github.com/encode/django-rest-framework/commit/af3fabfd517307fbc5d500fba1ab8f6e25f220b0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/encode/django-rest-framework"
    },
    {
      "type": "WEB",
      "url": "https://github.com/encode/django-rest-framework/releases/tag/3.18.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Django REST framework: TokenProxy.delete() reports success and revokes nothing"
}

CVE-2026-114137 (GCVE-0-2026-114137)

Vulnerability from cvelistv5 – Published: 2026-10-21 20:06 – Updated: 2026-10-21 20:06

Title

Django REST framework: TokenProxy.delete() reports success and revokes nothing

Summary

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.

Severity

7.4 (High)


                        
                          CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

CWE

CWE-390 - Detection of Error Condition Without Action
CWE-613 - Insufficient Session Expiration

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7664 records in the last 180 days details

References

3 references

URL	Tags
https://github.com/encode/django-rest-framework/s…	x_refsource_CONFIRM
https://github.com/encode/django-rest-framework/c…	x_refsource_MISC
https://github.com/encode/django-rest-framework/r…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
encode	django-rest-framework	Affected: >= 3.12.0, < 3.18.2

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "django-rest-framework",
          "vendor": "encode",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 3.12.0, \u003c 3.18.2"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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\u0027s 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\u0027s 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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 7.4,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-390",
              "description": "CWE-390: Detection of Error Condition Without Action",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-613",
              "description": "CWE-613: Insufficient Session Expiration",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-21T20:06:57.790Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/encode/django-rest-framework/security/advisories/GHSA-xw6w-gcfp-cf8m",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/encode/django-rest-framework/security/advisories/GHSA-xw6w-gcfp-cf8m"
        },
        {
          "name": "https://github.com/encode/django-rest-framework/commit/af3fabfd517307fbc5d500fba1ab8f6e25f220b0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/encode/django-rest-framework/commit/af3fabfd517307fbc5d500fba1ab8f6e25f220b0"
        },
        {
          "name": "https://github.com/encode/django-rest-framework/releases/tag/3.18.2",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/encode/django-rest-framework/releases/tag/3.18.2"
        }
      ],
      "source": {
        "advisory": "GHSA-xw6w-gcfp-cf8m",
        "discovery": "UNKNOWN"
      },
      "title": "Django REST framework: TokenProxy.delete() reports success and revokes nothing"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-114137",
    "datePublished": "2026-10-21T20:06:57.790Z",
    "dateReserved": "2026-10-20T21:53:58.473Z",
    "dateUpdated": "2026-10-21T20:06:57.790Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-XW6W-GCFP-CF8M

Summary

Details

PoC

Impact

CVE-2026-114137 (GCVE-0-2026-114137)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour