CVE-2026-61591

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.

Prior to version 1.0.7, many djust built-in component template tags render a developer/user-supplied URL into an href/action attribute, HTML-escaping it but never validating the URL scheme. HTML escaping prevents attribute breakout but does not neutralize a javascript: URI, so a URL like javascript:alert(document.cookie) lands verbatim in <a href="javascript:alert(document.cookie)"> and executes in the victim's session on click.

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.

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.