GHSA-29hf-rm4x-xxph — mise
MEDIUMGHSA-29hf-rm4x-xxph is a medium-severity (CVSS 6.3) OS Command Injection vulnerability in mise. A fix is available for mise — see the affected versions and patch details below.
Mise's local credential_command executes untrusted config
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-29hf-rm4x-xxph.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-29hf-rm4x-xxph plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,166 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
miseReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
Summary
mise loads github.credential_command from local project config before any trust decision, then executes that value with sh -c when resolving a GitHub token. An attacker who can place a .mise.toml in a repository can execute arbitrary shell commands when the victim runs a GitHub-related mise command and no higher-priority GitHub token environment variable is set.
The current command-execution path is github.credential_command. I confirmed in Docker that the setting is exploitable on v2026.3.15 and v2026.3.17, while v2026.3.14 rejects it as an unknown field. This report does not depend on the separate trust-bypass issue because the sink is reached directly from [settings.github].
Details
The vulnerable load order is:
Settings::try_get()preloads settings from local config files.parse_settings_file()returnssettings_file.settingswithout checking whether the local file is trusted.resolve_token()checkssettings.github.credential_commandafter the token env vars and before file-based sources.get_credential_command_token()executes the value withsh -c.
The main command-execution path is:
let result = std::process::Command::new("sh")
.arg("-c")
.arg(cmd)
.arg("mise-credential-helper")
.arg(host)
.output()
If a local project file sets:
[settings.github]
credential_command = "echo credential_command_rce > /tmp/mise-proof.txt; echo ghp_fake_token"
then resolve_token() will reach get_credential_command_token() whenever higher-priority GitHub token environment variables are unset. credential_command is a documented custom credential source for mise, but it is also accepted from a local project .mise.toml, which lets an untrusted repository supply a shell command for mise to execute.
PoC
Test environment:
- Docker
linux-arm64mise v2026.3.17
Negative control:
export GITHUB_TOKEN=env_token
mise github token --unmask
Observed:
github.com: env_token (source: GITHUB_TOKEN)
/tmp/mise-proof.txt => missing
Primary exploit:
[settings.github]
credential_command = "echo credential_command_rce > /tmp/mise-proof.txt; echo ghp_fake_token"
Run:
unset GITHUB_TOKEN GITHUB_API_TOKEN MISE_GITHUB_TOKEN MISE_GITHUB_ENTERPRISE_TOKEN
mise github token --unmask
Observed:
github.com: ghp_fake_token (source: credential_command)
And the side effect file is created:
/tmp/mise-proof.txt => credential_command_rce
Related version check:
v2026.3.14:credential_commandis rejected as an unknown fieldv2026.3.15: the same PoC executes and returnssource: credential_command
Impact
An attacker who can place a .mise.toml in a repository can execute arbitrary shell commands as the victim user when the victim runs a mise command that resolves a GitHub token from local settings.
Demonstrated impact:
- arbitrary command execution as the victim user
- no trust prompt
- no need for
[env],[hooks], tasks, or templates
Important limitation:
- if a higher-priority GitHub token environment variable is already set, the
credential_commandpath is not reached
Suggested Fix
Do not honor github.credential_command from non-global project config files.
For example, inside parse_settings_file():
pub fn parse_settings_file(path: &Path) -> Result<SettingsPartial> {
let raw = file::read_to_string(path)?;
let settings_file: SettingsFile = toml::from_str(&raw)?;
let mut settings = settings_file.settings;
if !config::is_global_config(path) {
settings.github.credential_command = None;
}
Ok(settings)
}
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | mise | ≥ 2026.3.15&&< 2026.6.4 | 2026.6.4cargo update -p mise --precise 2026.6.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for mise, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update mise to 2026.6.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-29hf-rm4x-xxph 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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-29hf-rm4x-xxph can be triaged on real exposure rather than presence alone.
Tailored to GHSA-29hf-rm4x-xxph. 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-29hf-rm4x-xxph in your dependencies?
O3 Security finds GHSA-29hf-rm4x-xxph across crates.io dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.