## 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.
## 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.
Update github.com/tilt-dev/tilt to 0.37.4 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanTilt: Missing authentication on the network-exposed Tilt HUD server affects github.com/tilt-dev/tilt (go). Severity is critical. ## 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.
AI coding agents often install or upgrade packages automatically in go. A critical vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/tilt-dev/tiltgo | >=0.20.8,<=0.37.3 | 0.37.4 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/tilt-dev/tilt to 0.37.4 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanTilt: Missing authentication on the network-exposed Tilt HUD server affects github.com/tilt-dev/tilt (go). Severity is critical. ## 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.
AI coding agents often install or upgrade packages automatically in go. A critical vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/tilt-dev/tiltgo | >=0.20.8,<=0.37.3 | 0.37.4 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard