GHSA-G47C-3XMW-Q6M2
Vulnerability from github – Published: 2026-09-01 19:24 – Updated: 2026-09-01 19:24Summary
AdminRenderer may disclose data that would normally be protected by GET permissions when rendering a 400 Bad Request response for an invalid write request.
If a view allows POST (or another write method) but denies GET, an invalid request rendered through AdminRenderer can invoke the view's GET handler and include data from the GET representation in the generated HTML response.
This behavior appears to be specific to AdminRenderer and does not affect the normal JSON rendering path.
Details
While investigating the AdminRenderer rendering flow, I observed that invalid write requests are rendered by temporarily overriding the request method and invoking the view's GET handler:
with override_method(view, request, "GET") as request:
response = view.get(request, *view.args, **view.kwargs)
data = response.data
This execution path differs from a normal GET request.
Under normal request processing, a GET request flows through:
APIView.dispatch()
└── APIView.initial()
└── APIView.check_permissions()
However, during AdminRenderer rendering, the renderer directly invokes:
view.get(...)
A view whose permission class explicitly allowed POST but denied GET still executed its GET handler while rendering an invalid POST request through AdminRenderer.
As a result, data intended to be available only through an authorized GET request was included in the generated HTML response.
Proof of Concept
Using a standard ListCreateAPIView.
Permission class:
class ProbePermission(BasePermission):
def has_permission(self, request, view):
return request.method == "POST"
View:
class View(ListCreateAPIView):
renderer_classes = (AdminRenderer, JSONRenderer)
permission_classes = (ProbePermission,)
serializer_class = ProbeSerializer
def get_queryset(self):
return [
{
"name": "visible",
"secret": "GET-ONLY-SECRET",
}
]
Expected Behaviour
GET request
→ 403 Forbidden
Invalid POST request
→ 400 Bad Request
→ Response should contain only validation errors.
→ GET-only data should not be rendered.
Observed Behaviour
GET request
→ 403 Forbidden
Invalid POST request rendered through AdminRenderer
→ 400 Bad Request
→ HTML response contains:
GET-ONLY-SECRET
Tthe same behavior is shown using a minimal APIView implementation.
Observed results:
minimal.post_400.handler_calls =
[
("post", "POST"),
("get", "GET")
]
minimal.post_400.contains_secret = True
Generic view reproduction:
generic.direct_get.status = 403
generic.direct_get.contains_secret = False
generic.post_400.status = 400
generic.post_400.contains_secret = True
generic.post_400.permission_calls =
[
("GenericAdminView", "POST"),
...
("GenericAdminView", "OPTIONS")
]
generic.post_400.queryset_calls =
[
("GenericAdminView", "GET"),
...
]
These observations indicate that direct GET requests are correctly denied, while the simulated GET used during AdminRenderer rendering can still retrieve the protected representation.
Impact
This issue may result in information disclosure when all of the following conditions are met:
AdminRenderer is enabled.
The client negotiates the HTML renderer (for example using Accept: text/html).
The application permits POST (or another write method).
GET requests are denied by the configured permission class.
The invalid write request returns 400 Bad Request.
The GET representation contains information that the requester would normally not be permitted to access.
This issue does not appear to affect:
JSON rendering
Standard API responses
Successful write requests
The behavior appears limited to the HTML rendering path used by AdminRenderer.
Suggested Fix
Possible approaches include:
Perform equivalent permission checks before executing the simulated GET request.
Avoid invoking view.get() when the corresponding GET request would not be permitted.
Fall back to rendering only serializer/form validation errors instead of retrieving the GET representation.
A regression test could create a permission class that allows POST while denying GET, then verify that an invalid POST rendered with AdminRenderer does not include data from the protected GET representation.
Environment
Repository:
encode/django-rest-framework
Branch tested:
security-audit-drf
Commit tested:
cf582fb58e9e5ffcc8ed78a2cb9aaa8f4865666a
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.17.1"
},
"package": {
"ecosystem": "PyPI",
"name": "djangorestframework"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.17.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73229"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-01T19:24:29Z",
"nvd_published_at": "2026-08-11T20:18:48Z",
"severity": "MODERATE"
},
"details": "Summary\n\nAdminRenderer may disclose data that would normally be protected by GET permissions when rendering a 400 Bad Request response for an invalid write request.\n\nIf a view allows POST (or another write method) but denies GET, an invalid request rendered through AdminRenderer can invoke the view\u0027s GET handler and include data from the GET representation in the generated HTML response.\n\nThis behavior appears to be specific to AdminRenderer and does not affect the normal JSON rendering path.\n\n\n---\n\nDetails\n\nWhile investigating the AdminRenderer rendering flow, I observed that invalid write requests are rendered by temporarily overriding the request method and invoking the view\u0027s GET handler:\n\n```\nwith override_method(view, request, \"GET\") as request:\n response = view.get(request, *view.args, **view.kwargs)\n\ndata = response.data\n```\n\nThis execution path differs from a normal GET request.\n\nUnder normal request processing, a GET request flows through:\n\n```\nAPIView.dispatch()\n \u2514\u2500\u2500 APIView.initial()\n \u2514\u2500\u2500 APIView.check_permissions()\n```\n\nHowever, during AdminRenderer rendering, the renderer directly invokes:\n\nview.get(...)\n\nA view whose permission class explicitly allowed POST but denied GET still executed its GET handler while rendering an invalid POST request through AdminRenderer.\n\nAs a result, data intended to be available only through an authorized GET request was included in the generated HTML response.\n\n\n---\n\nProof of Concept\n\nUsing a standard ListCreateAPIView.\n\nPermission class:\n\n```\nclass ProbePermission(BasePermission):\n def has_permission(self, request, view):\n return request.method == \"POST\"\n\nView:\n\nclass View(ListCreateAPIView):\n renderer_classes = (AdminRenderer, JSONRenderer)\n permission_classes = (ProbePermission,)\n serializer_class = ProbeSerializer\n\n def get_queryset(self):\n return [\n {\n \"name\": \"visible\",\n \"secret\": \"GET-ONLY-SECRET\",\n }\n ]\n```\n\nExpected Behaviour\n\n```\nGET request\n\u2192 403 Forbidden\n\nInvalid POST request\n\u2192 400 Bad Request\n\u2192 Response should contain only validation errors.\n\u2192 GET-only data should not be rendered.\n\n```\nObserved Behaviour\n\n```\nGET request\n\u2192 403 Forbidden\n\nInvalid POST request rendered through AdminRenderer\n\u2192 400 Bad Request\n\u2192 HTML response contains:\n\nGET-ONLY-SECRET\n```\n\nTthe same behavior is shown using a minimal APIView implementation.\n\nObserved results:\n\n```\nminimal.post_400.handler_calls =\n[\n (\"post\", \"POST\"),\n (\"get\", \"GET\")\n]\n\nminimal.post_400.contains_secret = True\n```\n\nGeneric view reproduction:\n\n```\ngeneric.direct_get.status = 403\ngeneric.direct_get.contains_secret = False\n\ngeneric.post_400.status = 400\ngeneric.post_400.contains_secret = True\n\ngeneric.post_400.permission_calls =\n[\n (\"GenericAdminView\", \"POST\"),\n ...\n (\"GenericAdminView\", \"OPTIONS\")\n]\n\ngeneric.post_400.queryset_calls =\n[\n (\"GenericAdminView\", \"GET\"),\n ...\n]\n```\n\nThese observations indicate that direct GET requests are correctly denied, while the simulated GET used during AdminRenderer rendering can still retrieve the protected representation.\n\n\n---\n\nImpact\n\nThis issue may result in information disclosure when all of the following conditions are met:\n\nAdminRenderer is enabled.\n\nThe client negotiates the HTML renderer (for example using Accept: text/html).\n\nThe application permits POST (or another write method).\n\nGET requests are denied by the configured permission class.\n\nThe invalid write request returns 400 Bad Request.\n\nThe GET representation contains information that the requester would normally not be permitted to access.\n\n\nThis issue does not appear to affect:\n\nJSON rendering\n\nStandard API responses\n\nSuccessful write requests\n\n\nThe behavior appears limited to the HTML rendering path used by AdminRenderer.\n\n\n---\n\nSuggested Fix\n\nPossible approaches include:\n\nPerform equivalent permission checks before executing the simulated GET request.\n\nAvoid invoking view.get() when the corresponding GET request would not be permitted.\n\nFall back to rendering only serializer/form validation errors instead of retrieving the GET representation.\n\n\nA regression test could create a permission class that allows POST while denying GET, then verify that an invalid POST rendered with AdminRenderer does not include data from the protected GET representation.\n\n\n---\n\nEnvironment\n\nRepository:\n\n`encode/django-rest-framework`\n\nBranch tested:\n\n`security-audit-drf`\n\nCommit tested:\n\n`cf582fb58e9e5ffcc8ed78a2cb9aaa8f4865666a`",
"id": "GHSA-g47c-3xmw-q6m2",
"modified": "2026-09-01T19:24:29Z",
"published": "2026-09-01T19:24:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/encode/django-rest-framework/security/advisories/GHSA-g47c-3xmw-q6m2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73229"
},
{
"type": "WEB",
"url": "https://github.com/encode/django-rest-framework/pull/10012"
},
{
"type": "WEB",
"url": "https://github.com/encode/django-rest-framework/commit/71f81946906e52f9dc8e5d22a0f3d2afa50c455e"
},
{
"type": "WEB",
"url": "https://github.com/encode/django-rest-framework/commit/9e82afc98acfe6fc28c9bf78147f0c5b3f222cb5"
},
{
"type": "PACKAGE",
"url": "https://github.com/encode/django-rest-framework"
},
{
"type": "WEB",
"url": "https://github.com/encode/django-rest-framework/releases/tag/3.17.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Django REST framework: AdminRenderer may disclose GET-protected data when rendering invalid write requests"
}
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.
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.