Summary The Tilt HUD HTTP server exposes state-changing and sensitive-read endpoints with no authentication. When the HUD is bound to a non-loopback address, a network attacker can trigger the developer's pre-defined Tiltfile resources, tamper with Tiltfile arguments, read full engine state including the session token, and reach the Tilt apiserver through a token-attaching proxy. Details The HUD server registers its handlers on a "gorilla/mux" router with no authenticating middleware. The "cookieWrapper" helper emits the "Tilt-Token" cookie but never validates it, and is attached only to the static-asset prefix. Impact An unauthenticated network caller can force any developer-defined resource to run on the host as the "tilt" user (choosing which and when, not the command text), set arbitrary Tiltfile arguments, disclose the session token and full engine state, and invoke apiserver resources via the loopback-token proxy. Because "tilt up" runs with the developer's privileges and credentials, the impact reaches the developer's environment and cluster. Conditions for exploitation - Affected version in ">= 0.20.8, <= 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") and ensure nothing else proxies to "localhost:10350". No complete workaround short of upgrading for non-loopback deployments.