GHSA-8wc6-vgrq-x6cf
MEDIUMChild processes spawned by Renovate incorrectly have full access to environment variables
Blast Radius
renovate📦renovateReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
When Renovate spawns child processes, their access to environment variables is filtered to an allowlist, to prevent unauthorized access to privileged credentials that the Renovate process has access to.
Since 42.68.1 (2025-12-30), this filtering had been inadvertently removed, and so any child processes spawned from these versions will have had access to any environment variables that Renovate has access to.
This could lead to insider attackers and outside attackers being able to exflitrate secrets from the Renovate deployment.
It is recommended to rotate (+ revoke) any credentials that Renovate has access to, in case any spawned child processes have attempted to exfiltrate any secrets.
Impact
Child processes spawned by Renovate (i.e. npm install, anything defined in postUpgradeTasks or postUpdateOptions) will have full access to the environment variables that the Renovate process has.
This could lead to insider attackers and outside attackers being able to exflitrate secrets from the Renovate deployment.
Patches
This is patched in 42.96.3 and 43.4.4.
Workarounds
There are no workarounds, other than upgrading your Renovate version.
Why did this happen?
As part of work towards https://github.com/renovatebot/renovate/security/advisories/GHSA-pfq2-hh62-7m96, one of the preparatory changes we made was moving to execa.
One of the default behaviours of execa is to extend the process' environment variables with any new ones, rather than override them.
This was missed in code review, which meant that since this version, the full environment variables have been provided to any child processes spawned with execa by Renovate.
This was discovered as part of an unrelated change.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | renovate | ≥ 42.68.1&&< 42.96.3 | 42.96.3 |
| 📦npm | renovate | ≥ 43.0.0&&< 43.4.4 | 43.4.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for renovate. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update renovate to 42.96.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-8wc6-vgrq-x6cf is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-8wc6-vgrq-x6cf is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-8wc6-vgrq-x6cf. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-8wc6-vgrq-x6cf in your dependencies?
O3 detects GHSA-8wc6-vgrq-x6cf across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.