Skip to content

Mise's local credential_command executes untrusted config

Moderate severity GitHub Reviewed Published Jun 12, 2026 in jdx/mise • Updated Jun 23, 2026

Package

mise (Rust)

Affected versions

>= 2026.3.15, < 2026.6.4

Patched versions

2026.6.4

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:

  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

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

References

@jdx jdx published to jdx/mise Jun 12, 2026
Published to the GitHub Advisory Database Jun 23, 2026
Reviewed Jun 23, 2026
Last updated Jun 23, 2026

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Local
Attack complexity
High
Privileges required
None
User interaction
Required
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(5th percentile)

Weaknesses

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component. Learn more on MITRE.

CVE ID

CVE-2026-55448

GHSA ID

GHSA-29hf-rm4x-xxph

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.