GHSA-c7c5-5j6r-q957: High severity pip/djust vulnerability
Impact djust's per-object authorization (getobject + hasobjectpermission, ADR-017) was enforced on the WebSocket mount and event paths but not on three other render entry points: (a) the initial HTTP GET render, (b) SPA urlchange navigation, and (c) {% liverender %} embedded child views. An authenticated user could therefore view (and on some paths act on) an object they are not authorized for by loading the page directly, navigating to it via SPA url-change, or composing it as an embedded child — a classic IDOR / broken object-level access control on object-scoped views.
Patches Fixed in djust 1.0.7. All render entry points now route through a shared enforceobjectpermission chokepoint: HTTP GET returns 403, urlchange emits a permissiondenied frame and skips the render, and {% liverender %} (eager + lazy) refuses the embed. Views without a custom getobject are unaffected (no-op).
Workarounds No reliable workaround short of upgrading. Do not expose object-scoped views through the HTTP-GET / urlchange / liverender paths until patched.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/djustto a version that resolves this vulnerability.Fixed in 1.0.7 - Upgrade
Upgrade
djustto a version that resolves this vulnerability.Fixed in 1.0.7 - Compensating control
Do not expose object-scoped views through the HTTP GET render, SPA `url_change` navigation, or `{% live_render %}` embedded child paths until patched.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using djust object-scoped views with custom get_object logic are exposed when those views can be reached through an initial HTTP GET, SPA url_change navigation, or a live_render embedded child view. Views without a custom get_object are unaffected.
What access does an attacker need?
An attacker needs to be authenticated and able to reach an object-scoped view through one of the affected render paths. They can attempt to load or navigate to an object for which they lack authorization.
How can we tell whether the patched behavior is active?
In the fix, unauthorized initial HTTP GET requests return HTTP 403, unauthorized url_change requests emit a permission_denied frame without rendering, and live_render refuses unauthorized embeds. The fix is in djust 1.0.7.
What should we do if we cannot upgrade immediately?
There is no reliable workaround short of upgrading. Until patched, do not expose object-scoped views through HTTP GET, url_change, or live_render paths.