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.