GHSA-436v-8fw5-4mj8

Описание

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:

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():

If a local project file sets:

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:

mise ls fails with:

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

Primary exploit:

with:

Then:

Observed:

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: