GHSA-xhhm-f6hp-2qwj: Critical severity pip/djust vulnerability
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.
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
Gate views using djust's `login_required` / `permission_required` / `check_permissions` attributes so they are honored on all transports (including WebSocket), rather than relying on HTTP-only Django mixins/decorators.
djust admin / authorization login_required / permission_required / check_permissions attributes = Use djust view attributes instead of HTTP-only mixins/decorators - Configuration
Ensure WebSocket authorization uses djust `check_view_auth` and that `check_view_auth` honors the Django `AccessMixin` family (so initial HTTP and WebSocket transports cannot diverge in authorization enforcement).
djust authentication runtime (check_view_auth / AccessMixin) check_view_auth honoring AccessMixin on all transports = Enabled - Configuration
Make sure the djust system check **S004** is present/enabled so it fails loud at startup on auth patterns the runtime cannot safely replay (e.g., decorator/overridden-`dispatch` forms).
djust system checks S004 = Fail at startup - Configuration
Use/update the djust admin base mixin so it declares `login_required = True` and an active-staff `check_permissions` gate, which is enforced for the admin base mixin across transports.
djust admin base mixin login_required and staff check_permissions gate = login_required = True; active-staff check_permissions gate
Event History
Frequently Asked Questions
What access does an attacker need to exploit this issue?
No authentication or privileges are required. An anonymous or under-privileged client can open a WebSocket, mount an affected view, and invoke its handlers.
Which authorization patterns are ineffective over the live WebSocket transport?
Django AccessMixin-based controls such as LoginRequiredMixin, PermissionRequiredMixin, and UserPassesTestMixin were bypassed, as were login_required decorators, custom dispatch() guards, and the djust admin extension's HTTP-only staff gate.
Are djust admin operations in scope?
Yes. The bypass can affect admin list, create, change, and delete views because the admin staff gate was applied only to the initial HTTP as_view wrapper rather than the WebSocket authorization path.
What can be done if an upgrade is not immediately possible?
Gate affected views with djust's login_required, permission_required, or check_permissions attributes, which are honored on all transports. Upgrade to djust 1.0.7 when possible.
How can unsafe authorization patterns be identified after upgrading?
djust 1.0.7 adds system check S004, which fails at startup for decorator-based and overridden-dispatch authorization patterns that the runtime cannot safely replay.