CVE-2026-61598

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.

The find_handlers_for_template MCP tool in python/djust/mcp/server.py from 0.9.0 until 1.0.10, 1.1.7, 1.2.4, and 1.3.0rc8 accepts an existing absolute template_path and reads it without restricting the resolved path to project directories. A local MCP client can use the tool as a file existence and readability oracle and obtain substrings matching the tool's attribute pattern from files readable by the djust process.

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.

djust before version 1.0.7 does not enforce per-object authorization (get_object + has_object_permission) on three render entry points: initial HTTP GET render, SPA url_change navigation, and {% live_render %} embedded child views. An authenticated user can view and act on objects they are not authorized for, a classic IDOR. This is fixed in djust 1.0.7.

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.

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.