CVE-2026-61594 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, the live (WebSocket) transport authorizes a mount via `check_view_auth`, not Django's `View.dispatch()` chain. As a result, standard Django authorization — `LoginRequiredMixin`, `PermissionRequiredMixin`, `UserPassesTestMixin`, `@method_decorator(login_required, name="dispatch")`, and custom `dispatch()` guards — and the djust admin extension's staff gate (applied only in the HTTP `as_view` wrapper) were enforced on the initial HTTP GET but silently bypassed over WebSocket, where all events and state flow. An anonymous or under-privileged client could open a WebSocket and mount such a view — including admin list/create/change/delete — and dispatch its handlers. This is fixed in djust 1.0.7. `check_view_auth` now honors the Django `AccessMixin` family on every transport; a new system check S004 fails loud at startup on auth patterns the runtime cannot safely replay (decorator/overridden-`dispatch` forms); and the admin base mixin declares `login_required = True` + an active-staff `check_permissions` gate. As a workaround, gate views using djust's `login_required` / `permission_required` / `check_permissions` attributes (honored on all transports) rather than HTTP-only mixins/decorators.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in the djust library prior to version 1.0.7 represents a critical authentication bypass affecting server-side rendering mechanisms that utilize WebSocket transport for real-time communication. The core issue stems from an architectural discrepancy where the live WebSocket connection authorizes view mounting through a specific function called check_view_auth, rather than routing through Django's standard View.dispatch() chain. This separation means that while initial HTTP GET requests are properly secured by Django’s robust authorization framework, subsequent interactions over the persistent WebSocket connection operate outside this protective boundary. Consequently, any security controls implemented via standard Django mixins such as LoginRequiredMixin, PermissionRequiredMixin, or UserPassesTestMixin, as well as custom dispatch guards and method decorators like login_required, are effectively ignored once a client establishes a WebSocket connection. This design flaw allows an attacker to bypass authentication checks that would normally restrict access based on user status or permissions.
From a technical perspective, this vulnerability is classified under CWE-287, which denotes Improper Authentication, as the system fails to correctly verify the identity of users during stateful interactions. Furthermore, it aligns with MITRE ATT&CK technique T1078, Valid Accounts, because an attacker can leverage valid but unauthenticated or insufficiently privileged credentials to access resources intended for authorized personnel only. The impact is particularly severe in administrative contexts where djust provides Phoenix LiveView-style reactive rendering for Django applications. An anonymous user or a client with limited privileges could open a WebSocket connection and mount views that are supposed to be restricted, including those within the djust admin extension. This includes critical operations such as listing, creating, changing, and deleting data entries in administrative interfaces. Since all events and state flow through this vulnerable channel, an attacker can execute arbitrary actions on behalf of authenticated users or perform unauthorized modifications without triggering any security alerts associated with standard HTTP request validation.
The operational impact of this vulnerability extends beyond simple information disclosure to include potential data integrity compromise and privilege escalation within the application’s administrative layer. Because the WebSocket transport handles real-time updates and state management, an attacker could manipulate live views, inject malicious payloads into reactive components, or exfiltrate sensitive data that is streamed over the connection. The lack of enforcement for standard Django authorization patterns means that developers relying on conventional security practices may have a false sense of security, believing their application is protected when it is not during real-time interactions. This discrepancy creates a significant attack surface where automated tools can easily probe and exploit the WebSocket endpoint to perform unauthorized actions, potentially leading to full system compromise if administrative functions are accessible through this vector.
To mitigate this vulnerability, users must upgrade djust to version 1.0.7 or later, which resolves the issue by ensuring that check_view_auth honors Django’s AccessMixin family on every transport mechanism. The updated implementation includes a new system check labeled S004, which fails loudly at startup if it detects authentication patterns that cannot be safely replayed over WebSocket connections, such as certain decorator-based or overridden dispatch forms. This proactive detection helps developers identify and rectify insecure configurations before deployment. For existing deployments where an immediate upgrade is not feasible, a workaround involves explicitly gating views using djust’s native login_required, permission_required, and check_permissions attributes rather than relying on HTTP-only Django mixins or decorators. These specific attributes are designed to be honored across all transports, ensuring that authentication checks remain consistent whether the client interacts via standard HTTP requests or persistent WebSocket connections. By aligning security controls with the transport-agnostic requirements of real-time applications, organizations can restore the integrity of their authorization models and prevent unauthorized access through live data channels.