CVE-2026-61596: Broken Object-Level Access Control (IDOR) in djust Framework

The djust Django framework provides reactive server-side rendering using a Rust-powered backend. It aims to deliver Phoenix LiveView-style reactivity inside Python environments. Prior to version 1.0.7, the framework contained an Insecure Direct Object Reference (IDOR) vulnerability identified as CVE-2026-61596.

This vulnerability allowed authenticated users to bypass object-level access controls. While permission checks were correctly executed over active WebSocket channels, they were completely omitted on several alternative rendering pathways. This architectural oversight exposed sensitive data to unauthorized requests.

The djust framework implements object-level authorization using the get_object and has_object_permission methods on views. This approach relies on fetching a database record and verifying that the requesting user possesses authorization to interact with that specific record.

In affected versions, these checks were restricted to the active WebSocket consumer lifecycle, specifically within the mount and event dispatch handlers. This design assumed all interaction would occur over persistent WebSocket connections. However, the framework exposes other pathways that render views without initializing a WebSocket session.

Three key paths bypassed these checks: synchronous HTTP GET rendering via RequestMixin.get and aget, client-side Single Page Application (SPA) navigation using ViewRuntime.dispatch_url_change, and embedded sub-views rendered with {% live_render %} template tags. Because these entry points lacked authorization validation, they fetched and displayed target objects without verifying the user's permissions.

The structural breakdown of this bypass can be represented as follows:

To resolve this vulnerability, version 1.0.7 introduced a consolidated authorization pipeline. The core authorization logic is centralized in the djust.auth.core.enforce_object_permission function, creating a single chokepoint for all rendering paths.

The updated implementation performs checks dynamically and fails closed by default. Below is a comparison demonstrating how the framework enforces access control during rendering:

# Affected Version (Simplified Behavior)
def render_http(request, view):
    # Vulnerable: Directly retrieves the object and renders the template
    # without calling has_object_permission checks.
    obj = view.get_object()
    return render(request, view.template_name, {"object": obj})
 
# Patched Version (Simplified Behavior)
from djust.auth.core import enforce_object_permission
from django.core.exceptions import PermissionDenied
 
def render_http(request, view):
    try:
        # Secure: The unified authorization chokepoint is evaluated first
        enforce_object_permission(request, view)
        obj = view.get_object()
        return render(request, view.template_name, {"object": obj})
    except PermissionDenied:
        # Handles unauthorized access gracefully by returning a 403 Forbidden response
        return HttpResponseForbidden("Permission Denied")

By routing the initial HTTP render, the SPA route changes, and the embedded views through enforce_object_permission, the framework blocks unauthorized rendering at the earliest stage of execution.

An attacker can exploit this IDOR vulnerability by targeting any of the three un-gated rendering pathways. No sophisticated payloads are required to trigger the bug, as it relies on standard browser navigation or manipulated API calls.

In a direct HTTP GET attack, an attacker with low-privileged credentials can identify a target URL containing an object identifier, such as /reports/99812/. By requesting this URL directly through a browser or using a command-line tool, the attacker bypasses the WebSocket connection entirely:

curl -H "Cookie: sessionid=<attacker_session_cookie>" https://example.com/reports/99812/

Because the server does not enforce has_object_permission on the synchronous HTTP GET path, it processes the request, retrieves the record from the database, and returns the fully rendered HTML page containing the unauthorized object's data to the attacker's console.

Similar bypasses occur when executing client-side routing changes within the SPA context. Manipulating the URL state prompts the backend to dispatch a url_change event, which executes without access checks and returns the sensitive state data.

The vulnerability has a High severity rating, primarily affecting confidentiality. Because of the missing access controls, any authenticated user can read arbitrary database records managed by the affected views simply by enumerating or predicting object identifiers.

While the primary impact is unauthorized information disclosure, there is a minor risk to integrity depending on the exposed templates. If the rendered DOM contains actionable forms or input elements that execute without further authorization checks, unauthorized users might manipulate state variables.

The CVSS v3.1 vector string is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, leading to a base score of 7.1. This indicates low complexity, requiring low privilege levels, and posing no threat to system availability.

The recommended remediation strategy is to upgrade djust to version 1.0.7 or later, which incorporates the centralized authorization architecture.

Administrators can update their installations using pip:

pip install --upgrade djust

If patching cannot be performed immediately, developers must implement manual authorization checks within custom dispatch or HTTP lifecycle hooks for all views utilizing get_object. Additionally, developers should write regression tests targeting the alternative rendering pathways to ensure permission coverage remains intact.