djust versions prior to 1.1.2 contain a vulnerability where a template binding inherits a context safety grant it never earned, leading to stored or reflected cross-site scripting (XSS). This occurs when a view marks a value safe (e.g., using mark_safe) and a template later rebinds that name to attacker-controlled input, causing the safety mark to be incorrectly retained. The issue affects multiple template binding constructs such as {% with %}, {% for %}, {% include … with %}, and assign tags. The vulnerability is fixed in version 1.1.2 and later.
Multiple template-layer defects in djust versions prior to 1.1.1 cause attacker-controlled input to be rendered as live markup without proper escaping, resulting in stored or reflected cross-site scripting (XSS). These defects affect various filters and template constructs, including linenumbers, escape, unordered_list, safeseq, render_slot, and linebreaks, allowing untrusted input to execute script code. The vulnerabilities require no special configuration and some are exploitable with typical application usage patterns. The issues are fixed in djust version 1.1.1 and later.
CVE-2026-61599 is a high-severity vulnerability in djust versions prior to 1.0.7 that allows unauthenticated WebSocket clients to cause the server to import and execute arbitrary Python modules. This occurs because the live transport resolves LiveView classes from client-supplied module paths using __import__ before validating the class or performing authentication. The default allowlist for permitted modules is fail-open and uses loose matching, enabling unsafe reflection and code execution. Version 1.0.7 introduces a fail-closed check that restricts imports to already loaded modules or explicitly allowed modules, preventing this unsafe behavior.
CVE-2026-61589 affects djust versions prior to 1.0.7 and involves incorrect tenant resolution due to the use of a less trusted source for the HTTP host in WebSocket request reconstruction. This causes tenant-scoped data managers to either return unscoped data (cross-tenant data disclosure) when STRICT_MODE is false or empty querysets when STRICT_MODE is true. The issue is fixed in version 1.0.7 by properly extracting and validating the Host header from the ASGI scope against ALLOWED_HOSTS.
CVE-2026-61596 is an authorization bypass vulnerability in djust prior to version 1.0.7. The flaw allows authenticated users to view or act on objects they are not authorized for via certain render entry points that did not enforce per-object authorization. This includes the initial HTTP GET render, SPA url_change navigation, and embedded child views using {% live_render %}. The issue is fixed in version 1.0.7 by routing all render entry points through a shared permission enforcement chokepoint. No reliable workaround exists other than upgrading.
djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, when a Django `Model` instance is assigned to a public view attribute, djust serialized it to the client with no sensitive-field denylist — sending fields such as `password` (the hash), privilege flags (e.g. `is_staff` / `is_superuser`), tokens, and other PII to the browser. Because exposing model objects to templates is a normal djust pattern, this could leak credentials/PII without the developer realizing the full object crossed the wire. This is fixed in djust 1.0.7. Model serialization applies a secure-by-default sensitive-field denylist (password/hash/token/secret-style fields and known privilege flags are withheld) with an identity-subset fallback. As a workaround, keep `Model` instances on `_private` attributes and expose only the specific fields needed, until patched.
CVE-2026-61594 is a critical vulnerability in djust versions prior to 1.0.7 where WebSocket transport bypasses standard Django authorization mechanisms. This allows anonymous or under-privileged clients to mount views and dispatch handlers over WebSocket that should be protected, including admin functions. The issue arises because authorization is checked via a custom method that does not enforce Django's usual access controls on WebSocket connections. The vulnerability is fixed in djust 1.0.7 by enforcing Django AccessMixin checks on all transports and introducing startup checks for unsafe auth patterns.
djust versions prior to 1.0.7 have a vulnerability where state snapshots embedded in client pages are not integrity-checked. This allows a client to modify unsigned state data, such as privilege flags or account information, and send it back to the server to escalate privileges or tamper with business state. The issue is fixed in version 1.0.7 by signing state snapshots and rejecting unsigned or forged snapshots. As a workaround, disabling state snapshots or avoiding storing authorization state in public view attributes mitigates the risk.
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` during mount and every event handler — and the tenant-aware `QuerySet` manager failed OPEN (returned the unfiltered queryset, ignoring `STRICT_MODE`), disclosing every tenant's rows to whoever held the socket. `threading.local` was additionally shared across connections on the `sync_to_async` executor thread. This issue is fixed in djust 1.0.7. Tenant storage moved to a `contextvars.ContextVar` (per async task); the resolved tenant is bound around WS/SSE mount and every dispatch; both managers scope the base queryset once and fail CLOSED (`.none()` under the default `STRICT_MODE`); and system check S006 warns when `STRICT_MODE=False`. No known workarounds are available on the live path.
djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, `djust.mixins.model_binding.ModelBindingMixin` provides a default `update_model` event handler and is part of the LiveView base MRO, so every LiveView exposes it. It `setattr`s a view attribute whose name is client-supplied (`field`), gated only by: reject `_`-prefixed names; reject a 14-entry denylist of framework internals (`FORBIDDEN_MODEL_FIELDS`); optional `allowed_model_fields` which defaults to None = allow all; and `hasattr` existence. As a result, a client can set any public, existing view attribute — not just the fields actually bound with `dj-model=` in the rendered template. The denylist covers framework plumbing but nothing about developer business/authz state, and the allowlist is opt-in (off by default). A developer who binds one `dj-model="search"` input and also keeps `self.account_id` / `self.is_admin` / `self.total_price` as view state does not realize a client can set ALL of them via `{type:event, event:"update_model", params:{field, value}}` over the WebSocket. Type coercion matches the target attribute's type (so `"true"` -> bool True), aiding the attacker. This issue is fixed in djust 1.0.7. As a workaround, set `allowed_model_fields` explicitly on every view using dj-model (or subclassing LiveView) to the minimal list of bindable fields; do not keep authorization/ownership state in public view attributes that share the view with dj-model bindings.