CVE-2026-61596: djust has broken object-level access control (IDOR)
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.
Other sources
djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, 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. This is 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). No reliable workaround short of upgrading. Do not expose object-scoped views through the HTTP-GET / urlchange / liverender paths until patched.
— MITRE
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, SPA `url_change`, or `{% live_render %}` embed render entry-point paths until patched.
Event History
Frequently Asked Questions
Which deployments are affected?
Deployments using djust versions before 1.0.7 are affected only where object-scoped views implement a custom get_object and rely on has_object_permission. Views without a custom get_object are unaffected.
What does an attacker need to exploit this?
An attacker must be authenticated and able to reach an object-scoped view. They can attempt to load an unauthorized object through an initial HTTP GET, SPA url_change navigation, or a live_render embedded child view.
What should teams do if they cannot upgrade immediately?
There is no reliable workaround short of upgrading to 1.0.7. Until patched, do not expose object-scoped views through HTTP GET, url_change, or live_render paths.
How does the fixed version handle unauthorized access?
Version 1.0.7 applies a shared object-permission check at all render entry points. Unauthorized HTTP GET requests return 403, url_change emits a permission_denied frame without rendering, and live_render refuses the embed.