Tilt: Cross-site WebSocket hijacking of the Tilt HUD stream

Description

## Summary The Tilt HUD WebSocket (`/ws/view`) is gated by a CSRF token, but the token is served by an unauthenticated endpoint and the upgrader accepts any client that omits an `Origin` header. When the HUD is network-exposed, an attacker can open the HUD stream and read the developer's session state. ## Details The upgrader accepts a connection when the `csrf` query parameter matches a process-wide token (`websocketCSRFToken`). That token is served as `text/plain` by an unauthenticated handler (`WebsocketToken`, mounted at `/api/websocket_token`), so any reachable caller can fetch it and connect to `/ws/view?csrf=<token>`. When the parameter does not match, the upgrader falls back to a same-origin check that returns true when the `Origin` header is absent, so a non-browser client that omits `Origin` is accepted anyway. The token has no per-session binding. ## Impact An attacker who can reach the HUD listener can open the HUD WebSocket and receive the full view stream — session state, Tiltfile contents, resource statuses, and continued updates — defeating the intended anti-CSWSH protection. ### Conditions for exploitation - Affected version in `>= 0.24.0, <= 0.37.3`. - HUD bound to a non-loopback address (`tilt up --host 0.0.0.0`, or `TILT_HOST` set). - Network reachability to the listener (default port `10350`). ### Not affected - The default loopback-only bind is not reachable from the network. ## Workarounds Use the default loopback bind (omit `--host`, unset `TILT_HOST`). No complete workaround short of upgrading for non-loopback deployments.

Affected Packages (1)