← Back to CVE List
CVE-2026-55884NVD
Vulnerability Summary
## 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.
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.