CVE-2026-103929

mise manages dev tools like node, python, cmake, and terraform. Prior to 2026.7.14, in the default non-safe mode, mise loads .mise.toml [settings] from an untrusted local project before trust approval and strip_local_only_settings removes only fields marked global_only. The unix_default_file_shell_args, unix_default_inline_shell_args, windows_default_file_shell_args, and windows_default_inline_shell_args settings were not marked global_only, allowing a repository to replace the default interpreter arguments used by trusted tasks that have no explicit shell, postinstall directives, template exec operations, or hooks that fall back to the default shell. When mise appends the trusted command after the attacker-controlled interpreter arguments, the attacker-selected command can execute first with the developer account's privileges even though the local configuration was never trusted. The separate path-sanitization hardening note in the advisory is outside this vulnerability. This issue is fixed in version 2026.7.14.

mise manages dev tools like node, python, cmake, and terraform. Prior to 2026.7.14, in the default non-safe mode, mise loads .mise.toml [settings] from an untrusted local project before trust approval and strip_local_only_settings removes only fields marked global_only. The unix_default_file_shell_args, unix_default_inline_shell_args, windows_default_file_shell_args, and windows_default_inline_shell_args settings were not marked global_only, allowing a repository to replace the default interpreter arguments used by trusted tasks that have no explicit shell, postinstall directives, template exec operations, or hooks that fall back to the default shell. When mise appends the trusted command after the attacker-controlled interpreter arguments, the attacker-selected command can execute first with the developer account's privileges even though the local configuration was never trusted. The separate path-sanitization hardening note in the advisory is outside this vulnerability. This issue is fixed in version 2026.7.14.

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' <command>.
• 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 <task> for a task defined in the global config or a trusted parent repo (inline run, no explicit shell); mise install of any tool with…

mise manages dev tools like node, python, cmake, and terraform. Prior to 2026.7.14, in the default non-safe mode, mise loads .mise.toml [settings] from an untrusted local project before trust approval and strip_local_only_settings removes only fields marked global_only. The unix_default_file_shell_args, unix_default_inline_shell_args, windows_default_file_shell_args, and windows_default_inline_shell_args settings were not marked global_only, allowing a repository to replace the default interpreter arguments used by trusted tasks that have no explicit shell, postinstall directives, template exec operations, or hooks that fall back to the default shell. When mise appends the trusted command after the attacker-controlled interpreter arguments, the attacker-selected command can execute first with the developer account's privileges even though the local configuration was never trusted. The separate path-sanitization hardening note in the advisory is outside this vulnerability. This issue is fixed in version 2026.7.14.

mise manages dev tools like node, python, cmake, and terraform. Prior to 2026.7.14, in the default non-safe mode, mise loads .mise.toml [settings] from an untrusted local project before trust approval and strip_local_only_settings removes only fields marked global_only. The unix_default_file_shell_args, unix_default_inline_shell_args, windows_default_file_shell_args, and windows_default_inline_shell_args settings were not marked global_only, allowing a repository to replace the default interpreter arguments used by trusted tasks that have no explicit shell, postinstall directives, template exec operations, or hooks that fall back to the default shell. When mise appends the trusted command after the attacker-controlled interpreter arguments, the attacker-selected command can execute first with the developer account's privileges even though the local configuration was never trusted. The separate path-sanitization hardening note in the advisory is outside this vulnerability. This issue is fixed in version 2026.7.14.

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' <command>.
• 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 <task> for a task defined in the global config or a trusted parent repo (inline run, no explicit shell); mise install of any tool with…