CVE-2026-61599
HighCVSS 8.8Summary
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.
Risk Assessment
An attacker can execute code at module import level (side effects), potentially leading to unauthorized access, data integrity compromise, or denial of service. Lack of required authentication increases the risk of remote exploitation.
Recommendation
Upgrade djust to version 1.0.7 or later. If upgrading is not possible, set a narrow LIVEVIEW_ALLOWED_MODULES list containing only modules with LiveView classes.
Other vulnerabilities in djust
See all- CVE-2026-61589Medium
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.
- CVE-2026-61588Medium
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.
- CVE-2026-61597Medium
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.
- CVE-2026-61592High
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.
- CVE-2026-61591High
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.
- CVE-2026-61595High
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.
- CVE-2026-61593High
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.
- CVE-2026-61598High
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.
- CVE-2026-61590High
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.
- CVE-2026-61594Critical
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.
Original NVD description (English source)
djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, the djust live transport resolves the LiveView to mount from a client-supplied dotted path by calling `__import__(module_path, ...)`. The module is imported — running its top-level code (import side effects) — before the framework checks that the resolved object is a `LiveView` subclass and before any per-view authentication. The `LIVEVIEW_ALLOWED_MODULES` allowlist that should contain this is fail-open (`if allowed_modules:` — skipped when the setting is unset, the framework default) and uses loose `startswith` matching. An unauthenticated WebSocket client (the WS handshake does not require auth; per-view auth runs only after import + instantiate) can therefore send a `mount` / `live_redirect_mount` / `url_change` frame (or an SSE mount) with `view = "<any.importable.module>.AnyName"` and cause the server to import — and execute the top-level code of — any importable Python module by name. Version 1.0.7 fixes the issue with a fail-closed resolution gate (`djust._view_resolution.is_view_import_allowed`): a client view path resolves only if (a) its module is already loaded (`sys.modules` — so resolving runs no new code; URL-routed views loaded by URLconf at startup keep working with zero config) or (b) it matches `LIVEVIEW_ALLOWED_MODULES` on a module-segment boundary (explicit opt-in for lazily-imported views). The gate runs before `__import__` at all three sinks (+ defense-in-depth inside `_instantiate_view`). As a workaround, set `LIVEVIEW_ALLOWED_MODULES` to the narrow list of modules that contain your mountable LiveView classes. (Note: pre-patch the allowlist is `startswith`-matched and the import still precedes the subclass check, so this is mitigation, not a complete fix.)

