CVE-2026-61596: 
Python vulnerability analysis and mitigation

CVE-2026-61596 is a broken object-level access control (IDOR) vulnerability in djust, a Phoenix LiveView-style reactive server-side rendering framework for Django with Rust-powered performance. The flaw affects all djust versions prior to 1.0.7 and was originally published on June 22, 2026, with the advisory added to the GitHub Advisory Database on September 16, 2026. An authenticated user can bypass per-object authorization (get_object + has_object_permission) on three render entry points — the initial HTTP GET render, SPA url_change navigation, and {% live_render %} embedded child views — to view or act on objects they are not authorized to access. It carries a CVSS v3.1 base score of 7.1 (High) (GitHub Advisory, djust Advisory).

The root cause is that djust's per-object authorization logic (ADR-017), implemented via get_object and has_object_permission, was only enforced on the WebSocket mount and event paths, leaving three additional render entry points unprotected (CWE-639: Authorization Bypass Through User-Controlled Key; CWE-862: Missing Authorization). An authenticated attacker can manipulate the object identifier in the URL or embed parameters to access unauthorized objects via: (a) a direct HTTP GET request to an object-scoped view URL, (b) SPA navigation using url_change events, or (c) composing the target view as an embedded child via {% live_render %}. The fix in version 1.0.7 introduces a shared enforce_object_permission chokepoint that all render entry points now route through, returning HTTP 403 on GET, emitting a permission_denied frame on url_change, and refusing the embed for {% live_render %} (GitHub Advisory, djust Advisory).

Successful exploitation allows an authenticated but low-privileged user to read objects they are not authorized to view (high confidentiality impact) and, on some render paths, perform unauthorized actions on those objects (low integrity impact). There is no availability impact. The vulnerability is scoped to object-level access control, meaning an attacker can enumerate and access other users' data records by manipulating object identifiers across multiple application entry points. Only views that implement a custom get_object method are affected; views without this customization are unaffected (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported for CVE-2026-61596. The EPSS score is 0.0, indicating a very low current probability of exploitation, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires authentication (low privileges), but no user interaction and low attack complexity, making it straightforward for any authenticated user to attempt (GitHub Advisory).

1. Authenticate: Obtain valid credentials for any low-privileged account on a djust application running a version prior to 1.0.7.
2. Identify object-scoped views: Browse the application to identify views that use get_object and has_object_permission for per-object authorization (e.g., detail pages with object IDs in the URL such as /items/42/).
3. Enumerate object identifiers: Increment or fuzz the object identifier in the URL (e.g., change /items/42/ to /items/43/, /items/44/, etc.) to discover objects belonging to other users.
4. Exploit HTTP GET path: Send a direct HTTP GET request to the target object URL. Because the authorization check is not enforced on this path, the server renders and returns the object's data regardless of the user's permissions.
5. Exploit SPA url_change path: If the application uses SPA navigation, trigger a url_change event pointing to the unauthorized object URL to receive the rendered object data via the SPA navigation mechanism.
6. Exploit live_render path: If the application supports embedded child views, compose a {% live_render %} tag referencing the unauthorized object-scoped view to receive its rendered output.
7. Exfiltrate or act on data: Use the returned object data for reconnaissance, data exfiltration, or further unauthorized actions depending on the application's functionality (GitHub Advisory, djust Advisory).

• Network: Repeated HTTP GET requests to object-scoped view URLs with sequentially or randomly varying object identifiers from a single authenticated session (IDOR enumeration pattern); unexpected access to object URLs by users who should not have permission.
• Logs: Django/djust access logs showing HTTP 200 responses for object-scoped URLs accessed by users who do not own or have explicit permission to those objects; absence of HTTP 403 responses on object-scoped GET paths in pre-1.0.7 deployments.
• Application Behavior: url_change navigation events in WebSocket logs targeting object IDs not associated with the authenticated user; live_render embed requests for object-scoped views from unauthorized sessions.

The vendor has released djust version 1.0.7, which fixes the vulnerability by routing all render entry points through a shared enforce_object_permission chokepoint. Upgrading to djust 1.0.7 or later via pip (pip install --upgrade djust) is the only reliable remediation. No effective workaround exists short of upgrading; as a temporary measure, operators should avoid exposing object-scoped views (those with custom get_object) through HTTP GET, url_change, or {% live_render %} paths until the patch is applied (GitHub Advisory, v1.0.7 Release).