Renovate self-hosted: child processes inherit the full environment, exposing every secret

Impact

Renovate spawns child processes - npm install, postUpgradeTasks, postUpdateOptions - without limiting the environment to an allowlist, so anything those processes run sees every environment variable held by the Renovate deployment. In a self-hosted install that set is the interesting one: git host tokens, container and package registry credentials, and whatever cloud credentials the runner was given. Since dependency install scripts execute code from the repositories being updated, a repo Renovate is configured to touch becomes a place from which those secrets can be read out. For a fleet where Renovate maintains node image tags, Helm charts or GPU operator versions, the stolen token is one that can push changes into what the cluster deploys.

Who can reach it

Anyone who can influence code executed by a Renovate child process - a contributor to a repository in scope, or an insider on the Renovate deployment. Low privilege is enough; no access to the Renovate host itself is needed.

What to do

Upgrade to 42.96.3 or 43.4.4 depending on the branch you track, and for the container deployments move renovate-ee-server / renovate-ee-worker off the 13.3.0-13.6.0 range; pull the fixed renovate/renovate or mend/renovate-ce image and restart the service or scheduled job. Because the exposure is credential theft that leaves no trace in the tool, rotate the tokens that were in the Renovate environment - git PATs, registry credentials, cloud keys - rather than only upgrading.

References