CVE-2026-61596 in djust
Summary
by MITRE • 09/17/2026
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 (`get_object` + `has_object_permission`, 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 `url_change` navigation, and (c) `{% live_render %}` 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 `enforce_object_permission` chokepoint: HTTP GET returns 403, `url_change` emits a `permission_denied` frame and skips the render, and `{% live_render %}` (eager + lazy) refuses the embed. Views without a custom `get_object` are unaffected (no-op). No reliable workaround short of upgrading. Do not expose object-scoped views through the HTTP-GET / url_change / live_render paths until patched.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in djust prior to version 1.0.7 represents a critical failure in access control mechanisms, specifically manifesting as broken object-level authorization within a reactive server-side rendering framework for Django. The core issue stems from an inconsistent enforcement of per-object permissions across different entry points used by the application. While the WebSocket mount and event paths correctly utilized the standard Django permission checks via get_object and has_object_permission methods aligned with ADR-017, three other critical render pathways were left unprotected. These unprotected vectors included the initial HTTP GET request for rendering a view, navigation events triggered by single-page application url_change mechanisms, and embedded child views rendered using the live_render template tag. This architectural inconsistency allowed authenticated users to bypass intended security boundaries simply by accessing these specific endpoints directly or through client-side navigation flows that did not trigger the WebSocket-based permission checks.
From a technical perspective, this flaw constitutes an Insecure Direct Object Reference vulnerability as defined in CWE-639 and falls under the category of Broken Access Control within CWE-284. The attacker exploits the disparity between server-side authorization logic applied to real-time communication channels versus standard HTTP request handling. When an authenticated user loads a page directly via HTTP GET, navigates using SPA url_change, or embeds a view that lacks proper permission validation, the application fails to verify if the current session holds the necessary rights for the specific object being accessed. Consequently, sensitive data can be viewed, and in certain configurations where write operations are permitted on these paths, unauthorized actions can be performed against resources belonging to other users or outside the user's authorized scope. This behavior aligns with MITRE ATT&CK technique T1078, Valid Accounts, as it leverages legitimate credentials to access restricted information due to flawed implementation of authorization controls rather than authentication failures.
The operational impact of this vulnerability is significant for any application relying on djust for secure object-scoped views. Users may inadvertently expose confidential data or allow unauthorized modifications by simply altering URLs or embedding components that were not intended for public or cross-user consumption. Since the initial HTTP GET and SPA navigation paths are common entry points for user interaction, the risk of exploitation is high without additional external controls. The vulnerability affects all object-scoped views where a custom get_object method is defined; views relying on default behavior remain unaffected as they do not engage this specific permission checking logic path that was found to be incomplete.
Mitigation requires an immediate upgrade to djust version 1.0.7 or later, which resolves the issue by routing all render entry points through a unified enforce_object_permission chokepoint. This centralized approach ensures consistent authorization checks regardless of whether the request originates from HTTP GET, SPA url_change events, or live_render embeds. For environments where upgrading is not immediately feasible, there are no reliable workarounds other than strictly avoiding exposure of object-scoped views through these specific vulnerable paths until the patch can be applied. Organizations should also review their access control policies to ensure that future implementations do not rely on fragmented permission checks across different request types and instead adopt a defense-in-depth strategy with centralized authorization middleware.