CVE-2026-73229

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 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", } ] ``` Ex