CVE-2026-103929: mise permits untrusted local configuration to override default shell arguments
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 striplocalonlysettings removes only fields marked globalonly. The unixdefaultfileshellargs, unixdefaultinlineshellargs, windowsdefaultfileshellargs, and windowsdefaultinlineshellargs settings were not marked globalonly, 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
miseto a version that resolves this vulnerability.Fixed in 2026.7.14
Event History
Frequently Asked Questions
Who is exposed to this issue?
Developers using mise before 2026.7.14 in its default non-safe mode are exposed when they run mise in or against an untrusted local project containing a .mise.toml file. The issue affects Unix and Windows default shell argument settings.
What must an attacker control for exploitation?
An attacker needs to supply a local project configuration that sets one of the default shell argument options. Exploitation also depends on mise executing a trusted task, postinstall directive, template exec operation, or hook that falls back to the default shell because it has no explicit shell configured.
Does the project configuration need to be trusted before it can affect execution?
No. Before the fix, mise loaded the relevant settings from an untrusted .mise.toml before trust approval, allowing those settings to alter default interpreter arguments despite the configuration not being trusted.
What should be done if upgrading is not immediately possible?
Avoid running mise in untrusted repositories or projects, particularly where local .mise.toml files may be attacker-controlled. Do not execute tasks or operations that fall back to mise's default shell in such projects.