feat: run unsafe executions (allowedUnsafeExecutions) like mise lock without exposing write token

[idelsink]

Tell us more.

When allowedUnsafeExecutions: ['mise'] is enabled, lib/modules/manager/mise/artifacts.ts resolves the host's GitHub token via findGithubToken and passes it directly as GITHUB_TOKEN to the mise trust + mise lock subprocess:

const token = findGithubToken(
  hostRules.find({ hostType: 'github', url: 'https://api.github.com/' }),
);
if (token) {
  extraEnv.GITHUB_TOKEN = token;
}

This token typically has write access (push branches, create PRs). A malicious mise.toml custom backend could execute arbitrary code during mise lock and exfiltrate it, which is the exact supply chain attack allowedUnsafeExecutions was meant to guard against.

It was flagged in #43606:

"Why is there a security issue here? You should be running this in a sandbox without secrets."

As a real-world example: my self-hosted runner (idelsink/renovate-runner) runs Renovate inside Docker with a scoped GitHub App token that has write permissions (workflow L128–139), injected as RENOVATE_TOKEN (workflow L207–218). The Docker container and ephemeral token limit blast radius, but the write token is still unnecessarily exposed during mise lock, which only needs read access to resolve checksums from GitHub releases.

Proposed solution

Split unsafe execution into two stages with different token scopes:

1. Compute stage: run mise trust + mise lock with a read-only token (or no token). Resolving checksums only requires read access to GitHub releases.
2. Commit stage: apply the resulting mise.lock changes using the write token via the normal Renovate update flow.

An optional unsafeExecutionToken hostRule (or self-hosted config key) could provide a lower-privilege token specifically for extraEnv.GITHUB_TOKEN during unsafe executions, falling back to current behaviour if not configured. This would generalise to future allowedUnsafeExecutions managers (e.g. goGenerate from #39163).

There is currently no workaround within Renovate's architecture. Docker isolation and ephemeral repo-scoped tokens are the only available mitigations.

AI usage: AI was used to find the exact paths on how the token is being ingested in into renovate codebase, the actual problem that is being raised is coming from me the human as I want security by default

[jamietanna]

@idelsink please don't tag users/maintainers in your Discussions. It adds unnecessary noise and spams their notifications.

Also, if you're using AI to contribute to Discussions, please make sure you disclose it.

[idelsink]

Sure let me make it more explicit remove the mention and added Ai note at the bottom

[jamietanna]

More generally:

• We could amend the token retrieval logic to use hostRules.readOnly and see if the user has configured a read-only token, yes - I'd be happy with accepting a change for that
• As noted, it's intended to be an unsafe executions, and risks that you have with passing credentials to how environment variables are handled in Renovate where there may be untrusted code is a risk to be taken into account as a self-hosted administrator

[idelsink]

Honestly I am not sure about where it should be configured and what the best place would be, my main concern is that we have a "sandboxed" renovate consuming a very broad token that, should be restricted when its running in a read-only context. e.g. when a mise lock is being called. I don't think its specific to the renovate self-shosted version as the mend hosted version has the same problem no? Or is there a specific feature that I am not aware about here?

That there can be a two step process, running renovate to generate a PR (locally) using the scoped non write permission, and the in another stage in another sandboxed environment use the write token to push the change and the PR?

[jamietanna]

Splitting the way Renovate works is not something we'd be looking to do at this time, as it increases complexity

[idelsink]

Hmm okok then probably this discussion can be closed 😅 but are there any long term plans on this kind of approach? To get better sandboxing capabilities?

[jamietanna]

Not at this point, no

We've got #43825 for hostRules.readOnly usage, but otherwise there's a balance between strong sandboxing and isolation, and making Renovate straightforward to set up and operate - we're more towards the former, but there's always work to do