GHSA-g47c-3xmw-q6m2: Infoleak
Summary
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 overridemethod(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.checkpermissions()
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 haspermission(self, request, view): return request.method == "POST"
View:
class View(ListCreateAPIView): rendererclasses = (AdminRenderer, JSONRenderer) permissionclasses = (ProbePermission,) serializerclass = ProbeSerializer
def getqueryset(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.post400.handlercalls = [ ("post", "POST"), ("get", "GET") ]
minimal.post400.containssecret = True
Generic view reproduction:
generic.directget.status = 403 generic.directget.containssecret = False
generic.post400.status = 400 generic.post400.containssecret = True
generic.post400.permissioncalls = [ ("GenericAdminView", "POST"), ... ("GenericAdminView", "OPTIONS") ]
generic.post400.querysetcalls = [ ("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 Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/djangorestframeworkto a version that resolves this vulnerability.Fixed in 3.17.2 - Configuration
Avoid invoking the view.get() / GET handler during AdminRenderer rendering when the corresponding GET request would not be permitted by the view's permission class; if rendering an invalid write request (e.g., 400 Bad Request), fall back to rendering only serializer/form validation errors instead of retrieving the protected GET representation.
AdminRenderer (HTML rendering path) Invoke GET handler during AdminRenderer rendering = false - Configuration
When AdminRenderer simulates a GET request for an invalid write request, perform equivalent permission checks (per the view's permission_classes) before executing the simulated GET handler; do not allow rendering of GET-only data if GET is denied (e.g., permission class allows POST but denies GET).
APIView.check_permissions() / simulated GET during AdminRenderer rendering Permission checks for simulated GET = performed
Event History
Frequently Asked Questions
Which deployments are exposed to this behavior?
Exposure requires use of AdminRenderer on a view that permits a write method such as POST while denying GET. The issue occurs when an invalid write request is rendered as an HTML 400 response.
What access does an attacker need?
The attacker needs permission to make the allowed write request to the affected view. They must submit an invalid request that causes a 400 Bad Request response to be rendered through AdminRenderer.
Are normal JSON API responses affected?
No. The behavior appears specific to AdminRenderer and does not affect the normal JSON rendering path.
Why can data be exposed even though GET is denied?
While rendering the invalid write response, AdminRenderer temporarily changes the request method to GET and directly invokes the view's GET handler. This bypasses the normal GET dispatch path where permission checks would ordinarily run.