Five independent defects in djust's template auto-escaping cause attacker-controlled input to be rendered as live markup where Django escapes it. All four are present in shipped 1.1.0 and are fixed in 1.1.1. They share one shape: a filter or grant that escapes nothing itself and relies on the render-time auto-escape, which something downstream then removes. They are grouped into a single advisory because the mitigation is identical — upgrade to …
A context safety grant was inherited by a template binding that never earned it, so rebinding a name the view had marked safe left the mark attached to the new, attacker-controlled value. djust's context safety channel is keyed by name, not by value. Every bind copied the value and left the grant in place: view marks p = mark_safe('<b>trusted</b>') template {% with p=user_input %}{{ p }}{% endwith %} djust '<img …
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.
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.
The WebSocket handle_mount and ViewRuntime._build_request rebuild an HttpRequest via RequestFactory().get(…) with no HTTP_HOST, so request.get_host() defaulted to "testserver" on the live path. Host/subdomain/domain TenantResolvers then misresolved the tenant — None on the live path while the HTTP path resolved correctly. With STRICT_MODE=False the tenant-scoped managers returned unscoped rows (cross-tenant disclosure); with the default they returned an empty queryset (broken tenancy).
For views that opt into state snapshots, the snapshot state_json embedded in the client page was restored on reconnect as trusted view state with no integrity check. A client could edit the unsigned state_json in their page and return it in the reconnect mount frame to inject arbitrary view attributes — e.g. flip is_admin to True, or change account_id / balance — escalating privilege or tampering with business state held …
SSE sessions were keyed solely by a client-chosen session_id with no binding to the authenticated user — a control the WebSocket transport has but that was dropped on SSE. An attacker who learns (or a victim who leaks) a session_id could connect to the message endpoint and dispatch event handlers that execute with the victim's identity and state.
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 …
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 setattrs 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. Result: a client can set any public, existing view attribute — not just the …
Many djust built-in component template tags (djust.components.templatetags.*) render a developer/user-supplied URL into an href / action attribute, HTML-escaping it with conditional_escape but never validating the URL scheme. HTML escaping prevents attribute breakout but does not neutralize a javascript: URI (which needs no escapable characters), so a URL value of javascript:alert(document.cookie) lands verbatim in <a href="javascript:alert(document.cookie)"> and executes in the victim's session on click. Affected sinks (executing href/action contexts; not exhaustive): …
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: force the victim's browser to GET the stream URL (which creates and mounts a LiveView as the victim) and POST to the message endpoint with credentials: include to fire state-changing event handlers as the victim. The URL session_id is client-chosen (validated only for …
djust's per-object authorization (get_object + has_object_permission, ADR-017) was enforced on the WebSocket mount and event paths but not on three other render entry points: (a) the initial HTTP GET render, (b) SPA url_change navigation, and (c) {% live_render %} embedded child views. An authenticated user could therefore view (and on some paths act on) an object they are not authorized for by loading the page directly, navigating to it via …
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 …
The live (WebSocket) transport authorizes a mount via check_view_auth, not Django's View.dispatch() chain. As a result, standard Django authorization — LoginRequiredMixin, PermissionRequiredMixin, UserPassesTestMixin, @method_decorator(login_required, name="dispatch"), and custom dispatch() guards — and the djust admin extension's staff gate (applied only in the HTTP as_view wrapper) were enforced on the initial HTTP GET but silently bypassed over WebSocket, where all events and state flow. An anonymous or under-privileged client could open a …
djust's LiveViewConsumer mounts a LiveView over a WebSocket. When a view is gated (login_required / permission_required, or an on_mount hook that returns a redirect) and the connecting user is not authorized, the consumer sent the client a {"type":"navigate","to":…} redirect frame and then returned — without closing the socket and without clearing self.view_instance. Only the PermissionDenied branch closed the connection (close(4403)). A real browser obeys the navigate frame and leaves, hiding …