CVE-2026-61594: djust has an authorization bypass on the WebSocket/SSE mount path
Impact The live (WebSocket) transport authorizes a mount via checkviewauth, not Django's View.dispatch() chain. As a result, standard Django authorization — LoginRequiredMixin, PermissionRequiredMixin, UserPassesTestMixin, @methoddecorator(loginrequired, name="dispatch"), and custom dispatch() guards — and the djust admin extension's staff gate (applied only in the HTTP asview 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.
Patches Fixed in djust 1.0.7. checkviewauth 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 loginrequired = True + an active-staff checkpermissions gate.
Workarounds Gate views using djust's loginrequired / permissionrequired / checkpermissions attributes (honored on all transports) rather than HTTP-only mixins/decorators.
Other sources
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 checkviewauth, not Django's View.dispatch() chain. As a result, standard Django authorization — LoginRequiredMixin, PermissionRequiredMixin, UserPassesTestMixin, @methoddecorator(loginrequired, name="dispatch"), and custom dispatch() guards — and the djust admin extension's staff gate (applied only in the HTTP asview 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. checkviewauth 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 loginrequired = True + an active-staff checkpermissions gate. As a workaround, gate views using djust's loginrequired / permissionrequired / checkpermissions attributes (honored on all transports) rather than HTTP-only mixins/decorators.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/djustto a version that resolves this vulnerability.Fixed in 1.0.7 - Upgrade
Upgrade
djustto a version that resolves this vulnerability.Fixed in 1.0.7 - Configuration
As a workaround, gate Django views using djust's `login_required` / `permission_required` / `check_permissions` attributes (honored on all transports) rather than HTTP-only mixins/decorators.
djust login_required / permission_required / check_permissions (view attributes) = use these attributes to gate views
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using djust views that rely on Django dispatch-based authorization are exposed on the live WebSocket transport. This includes views protected by Django AccessMixin-based controls, dispatch decorators or custom dispatch guards, and djust admin views whose staff restriction was applied only through the HTTP wrapper.
What does an attacker need to exploit it?
An attacker can be anonymous or under-privileged and does not need user interaction. They need network access to open a WebSocket connection and mount an affected view, after which they can dispatch that view's handlers.
Are djust admin operations affected?
Yes. The issue can allow mounting djust admin list, create, change, and delete views over WebSocket when the staff gate is only enforced by the initial HTTP as_view wrapper.
What can be done if upgrading is not immediately possible?
Gate affected views with djust's login_required, permission_required, or check_permissions attributes, which are honored on all transports. The fixed release is djust 1.0.7.
How does the fixed version help identify unsafe authorization patterns?
djust 1.0.7 adds system check S004, which fails loudly at startup when it finds decorator-based or overridden-dispatch authorization patterns that the runtime cannot safely replay.