Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-09-16T22:17:03.047Z",
  "pubdate": "2026-09-16T22:17:03.047Z",
  "executiveSummary": "A critical authorization bypass vulnerability exists in djust versions prior to 1.0.7, affecting the framework's reactive server-side rendering implementation.\nThe vulnerability originates from a decoupling of the WebSocket transport layer from standard Django middleware and dispatch-level authorization mechanisms, such as LoginRequiredMixin or @method_decorator(login_required, name='dispatch').\nWhile initial HTTP GET requests correctly triggered standard Django security guards, subsequent interactions over the persistent WebSocket transport were authorized solely via the check_view_auth function, which failed to adequately replicate these protections.\nConsequently, unauthenticated or unauthorized users could establish a WebSocket connection and gain direct access to protected views, including administrative list, create, change, and delete operations.\nThis represents a severe security flaw as it permits full unauthorized access to backend business logic and administrative functions, bypassing the intended Django security lifecycle entirely.\nAttackers do not require pre-existing credentials or special privileges to exploit this, provided they can initiate a WebSocket connection to the vulnerable view endpoint.",
  "technicalDetails": "The root cause of this vulnerability is an architectural inconsistency in how the djust framework handles authentication across different transport layers. In Django, security constraints are typically enforced within the View.dispatch() method or via class-based view mixins that hook into the dispatch lifecycle. However, djust handled the initial HTTP mount phase separately from the live WebSocket event stream.\nBefore version 1.0.7, the WebSocket transport utilized a custom check_view_auth function to authorize view mounts. This mechanism did not interoperate with or re-evaluate the Django AccessMixin family of security decorators or overridden dispatch() methods used in standard Django development. Because the WebSocket connection persists and handles state flow independently of the initial HTTP context, the authorization logic enforced on the GET request was not carried over or re-validated during subsequent WebSocket event processing.\nThe attack flow follows a predictable pattern: An attacker identifies a djust-powered view secured only via traditional Django mechanisms like LoginRequiredMixin or permission-based decorators. The attacker then initiates a WebSocket connection to the djust mount point. Because the server-side check_view_auth function does not account for the standard Django authentication guards, the WebSocket connection is successfully established. Once the mount is authorized, the attacker can dispatch arbitrary handlers associated with that view, effectively bypassing all authentication and authorization layers that would have blocked them had they attempted to interact with the view via standard HTTP.\nThis vulnerability is particularly impactful regarding the djust admin extension. The admin staff gate was historically applied only within the HTTP as_view() wrapper. Since the WebSocket transport effectively bypassed this wrapper, an unauthorized client could gain full administrative control over data models. The flaw allows remote attackers to execute sensitive operations, including privilege escalation, data exfiltration, or unauthorized modification of system resources, as the backend assumes the authorization state of the WebSocket session is inherently trusted if it passes the insufficient check_view_auth logic.\nPost-exploitation, the attacker maintains full reactive control over the view instance, allowing for continuous, unauthorized interaction with the server-side state. The absence of per-event authorization checks within the WebSocket stream allows an attacker to remain active within the session without re-authenticating, as the connection state is decoupled from the Django request-response cycle."
}