Repository navigation
ZERO_DAEMON_REMOTE_TOKEN_FILE leaks the daemon bearer token into sandboxed commands #677
Description
Activity
Confirmed on current
main, and fixed in #818.scrubSensitiveEnv(internal/sandbox/runner.go:1008) listsZERO_DAEMON_REMOTE_TOKENand nothing matchesZERO_DAEMON_REMOTE_TOKEN_FILE, whileTokenFromEnvaccepts either form. So the pointer survived into the sandboxed environment and the read-all posture did the rest.The fix is the one line plus a test. I deliberately did not also add the target to the credential deny-read list: the path comes from that variable alone and there is no default location to guess at, so scrubbing it closes the leak outright, and touching the deny-read builder would collide with #816 for no extra protection.
- added a commit that references this issue
on Jul 28, 2026 - added a commit that references this issue
on Jul 29, 2026
Summary
PR #660 scrubs
ZERO_DAEMON_REMOTE_TOKEN, but leavesZERO_DAEMON_REMOTE_TOKEN_FILEin the inherited sandbox environment. The read-all sandbox posture lets the command read the referenced file.Relevant code
internal/sandbox/runner.go:scrubSensitiveEnvincludesZERO_DAEMON_REMOTE_TOKENbut notZERO_DAEMON_REMOTE_TOKEN_FILE.internal/daemon/remote/auth.go:TokenFromEnvreads the bearer token from that path.Observed at commit
6fc1220.Reproduction
ZERO_DAEMON_REMOTE_TOKEN_FILEto its absolute path.Suggested fix
Remove the pointer from the sandbox environment and add its resolved target to
DenyRead, analogous toGOOGLE_APPLICATION_CREDENTIALS. Test both env scrubbing and filesystem denial.