Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
MEDIUM severity

Django REST framework: AdminRenderer may disclose GET-protected data when rendering invalid write requestsGHSA-g47c-3xmw-q6m2

MEDIUMFix: encode/django-rest-framework#10012

GHSA-g47c-3xmw-q6m2 is a medium-severity (CVSS 4.3) Information Exposure vulnerability in djangorestframework. A fix is available for djangorestframework — see the affected versions and patch details below.

Also known asCVE-2026-73229PYSEC-2026-3828
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 16, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-g47c-3xmw-q6m2.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs30th percentile — riskier than 30% of all scored CVEsHighest risk
0.00%0.29%0.58%0.87%0.3%0.4%0.4%Sep 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-g47c-3xmw-q6m2 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 390,400 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐍djangorestframework

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

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

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 Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIdjangorestframeworkall versions3.17.2pip install --upgrade 'djangorestframework==3.17.2'

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for djangorestframework, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update djangorestframework to 3.17.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-g47c-3xmw-q6m2 is resolved across your whole dependency graph.

  3. Workarounds

    Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate

This vulnerability is rated as Moderate impact because information exposure is restricted to scenarios where the AdminRenderer HTML renderer is explicitly utilized alongside asymmetric permissions that forbid read operations while allowing writes. In typical Red Hat deployments, API services predominantly process JSON…

Workaround published by Red Hat
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
Source: Red Hat security advisory for GHSA-g47c-3xmw-q6m2 (CC BY 4.0)

Frequently Asked Questions

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 re
O3 Security · Impact-Aware SCA

Is GHSA-g47c-3xmw-q6m2 in your dependencies?

Find it across PyPI, including transitive dependencies.

Django REST framework: AdminRenderer may disclose…