CVE-2026-55571 in djust
Summary
by MITRE • 08/25/2026
djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to 1.0.4, LiveViewConsumer.handle_mount sends a `{"type":"navigate","to":...}` frame when login_required, permission_required, or a redirecting on_mount hook denies a LiveView mount, but returns without closing the WebSocket or clearing self.view_instance. A browser follows the redirect, but a raw WebSocket client can ignore it and retain the mounted socket. Because LiveViewConsumer.handle_event does not recheck authentication or authorization, the client can send `{"type":"event",...}` frames that invoke @event_handler methods without an authenticated session, including through handle_live_redirect_mount, enabling unauthorized sensitive reads or mutations. This issue is fixed in version 1.0.4.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified in djust prior to version 1.0.4 represents a critical authentication bypass and authorization failure within the reactive server-side rendering framework for Django. The core of this flaw lies in the lifecycle management of WebSocket connections during mount operations that require user authentication or specific permissions. When a LiveViewConsumer.handle_mount function encounters conditions such as login_required, permission_required, or an on_mount hook designed to redirect unauthenticated users, it correctly sends a navigation frame instructing the client to move to a different location. However, the implementation fails to properly terminate the underlying WebSocket connection or clear the self.view_instance state associated with that socket. This incomplete cleanup creates a persistent session context for connections initiated by clients that do not follow standard browser-based redirect behaviors.
In typical web applications using browsers, users are automatically redirected when they attempt to access protected resources without proper credentials. However, raw WebSocket clients can intercept or ignore these navigation instructions and maintain the active connection established during the initial mount phase. Because the server-side state for this socket remains intact despite the denied authorization check, the application continues to treat the client as if it were successfully authenticated and authorized for that specific LiveView instance. This discrepancy between the intended security policy and the actual runtime state allows an attacker to retain access to a mounted view without possessing valid credentials or permissions.
The severity of this vulnerability is amplified by the fact that subsequent event handling does not re-evaluate authentication or authorization status. When a client sends frames with type "event" to invoke @event_handler methods, including those triggered through handle_live_redirect_mount mechanisms, the server processes these requests based on the stale session context established during the mount phase. Consequently, an attacker can execute sensitive read operations or perform unauthorized mutations against Django models and application logic without ever successfully logging in or obtaining the necessary permissions. This effectively bypasses all security controls intended to restrict access to specific views or actions within the LiveView architecture.
This issue aligns with CWE-287 Improper Authentication, as the system fails to correctly verify identity before granting persistent session privileges, and CWE-306 Missing Authentication for Critical Function, since event handlers are executed without re-validating user rights. From an ATT&CK perspective, this vulnerability facilitates Initial Access through exploitation of misconfigured authentication flows and can lead to Privilege Escalation if the mounted view provides access to higher-level administrative functions or sensitive data processing capabilities. The lack of state cleanup upon authorization failure is a common pitfall in WebSocket-based applications where connection lifecycle management must be strictly coupled with security checks.
To mitigate this vulnerability, it is essential to ensure that any mount operation resulting in denial of access immediately terminates the associated WebSocket connection and clears all related server-side instance data. This prevents the socket from remaining open for further interaction under a false premise of authorized status. Upgrading djust to version 1.0.4 or later resolves this issue by implementing proper cleanup procedures when authentication or permission checks fail during the mount phase. Additionally, developers should consider implementing re-verification of session validity before processing any event frames that modify state or expose sensitive data, adding a defense-in-depth layer against similar logic flaws in reactive web frameworks.