CVE-2026-55571

### Impact 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 `return`ed — **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 the problem. A **raw WebSocket client that ignores the redirect** keeps an open, mounted socket. Because `handle_event` did not re-check authentication/authorization after mount, that client could then send `{"type":"event", ...}` frames and invoke any `@event_handler` method on the gated view **with no authenticated session** — an authentication bypass on the live mutation path. **Who is affected:** apps that expose `LiveView`s gated by `login_required` / `permission_required` / a redirecting `on_mount` hook, where the gated view's event handlers perform sensitive reads or mutations and do not independently re-verify the user. Exploitation requires a non-browser WebSocket client and knowledge (or enumeration) of the view path and event names. ### Patches Fixed in **djust 1.0.4** (commit `1ae8aa9`, PR #1780). Both the auth-redirect and `on_mount`-hook-redirect branches of `handle_mount` now send the navigate frame **and then `close(code=4403)` and clear `self.view_instance`**, mirroring the existing `PermissionDenied` branch. Public / authorized mounts are unchanged. The same path is reachable via `handle_live_redirect_mount` (which delegates to `handle_mount`) and is covered by the same fix. 1.0.4 also adds an opt-in defense-in-depth control, `LIVEVIEW_CONFIG['reauth_on_event'] = True` (default OFF), which re-resolves the user from the session and re-runs the view's auth check on **every** event for gated views. ### Workarounds Upg