CVE-2026-61597

A vulnerability in the djust library (before version 1.0.7) allows an unauthenticated WebSocket client to trigger the import of any Python module via a crafted view path. The import occurs before LiveView class verification and authentication, and the allowed modules list is fail-open by default with loose startswith matching.

In djust before version 1.0.7, the WebSocket path (handle_mount and ViewRuntime._build_request) rebuilds HttpRequest without HTTP_HOST, causing get_host() to default to "testserver". This leads to incorrect tenant resolution on the live path — with STRICT_MODE=False it can cause cross-tenant disclosure, and with the default it returns empty querysets. Fixed in 1.0.7.

In djust before version 1.0.7, assigning a Django Model instance to a public view attribute serialized the entire object to the client without a sensitive-field denylist. This sent fields such as password hashes, privilege flags (is_staff, is_superuser), tokens, and other PII to the browser. Fixed in 1.0.7.

In djust prior to version 1.0.7, SSE sessions were keyed solely by a client-chosen session_id with no binding to the authenticated user. An attacker who learns a victim's session_id could connect to the message endpoint and dispatch event handlers executing with the victim's identity and state.

In djust prior to version 1.0.7, for views using state snapshots, the state_json embedded in the client page was restored on reconnect as trusted view state without integrity checks. A client could edit the unsigned state_json to inject arbitrary view attributes, such as flipping is_admin to True or changing account_id/balance.

djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, djust.tenants isolation was enforced only on the HTTP path; the current tenant was stored in threading.local() and set exclusively by the HTTP-only TenantMiddleware, so on the live (WebSocket/SSE) path get_current_tenant() was always None and the tenant-aware QuerySet manager failed OPEN, disclosing every tenant's rows. This issue is fixed in djust 1.0.7.

djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, the SSE client→server POST endpoints are @csrf_exempt and the SSE GET stream endpoint had no Origin check, so a cross-origin page could drive a victim-cookie-authenticated SSE session and fire state-changing event handlers as the victim. This issue is fixed in 1.0.7.

A vulnerability in djust (versions prior to 1.0.7) affects the default `update_model` event handler in `ModelBindingMixin`, allowing a client to set any public, existing view attribute over the WebSocket, not just fields bound with `dj-model=`. Protection relies only on rejecting `_`-prefixed names, a 14-entry denylist of framework internals, and an optional allowlist that defaults to allowing all. As a result, an attacker can modify attributes such as `account_id`, `is_admin`, or `total_price` if they are public and exist on the view.

Prior to version 1.0.7, djust's observability endpoints expose live view/session state and a remote method-invocation surface (eval_handler). The localhost restriction was an opt-in middleware that the documented setup omits; the views themselves enforced only DEBUG. In the misconfigured-but-documented scenario (DEBUG on, middleware not installed) a non-localhost client could read live application state and invoke handlers remotely.

djust prior to version 1.0.7 has a vulnerability in the WebSocket transport that bypasses standard Django authorization mechanisms (such as LoginRequiredMixin, PermissionRequiredMixin, etc.) and the staff gate in the admin extension. Mount authorization is done via check_view_auth, not the View.dispatch() chain, allowing anonymous or under-privileged clients to open a WebSocket and dispatch view handlers, including admin ones.