GHSA-6m68-r693-78qx Tilt: Cross-site WebSocket hijacking of the Tilt HUD stream

• Go github.com/tilt-dev/tilt: >= 0.24.0, < 0.37.4 → fixed in 0.37.4

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=`. 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.