CVE-2026-55441 in mise
Summary
by MITRE • 06/26/2026
mise manages dev tools like node, python, cmake, and terraform. Prior to 2026.6.4, mise's trust feature gates config files (mise.toml, .tool-versions) through trust_check, but task-include files are loaded on a path that never reaches it. When a directory has a task-include dir (mise-tasks/, .mise/tasks/, …) but no config file, mise falls back to the default includes and renders each task's tera fields — and that tera environment has exec() registered. A {{ exec(command='…') }} in any rendered field runs arbitrary commands the moment the tasks are merely listed. There's no config file to gate on, so no trust prompt ever appears. Read-only commands trigger it: mise tasks, mise task ls, mise run, mise tasks --usage (the query shell completion runs on Tab). The victim only has to cd into a cloned repo and list or tab-complete a task. This vulnerability is fixed in 2026.6.4.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 06/26/2026
This vulnerability affects the mise toolchain management system, which handles development tools including node, python, cmake, and terraform. The flaw exists in how mise processes task inclusion files without proper trust validation mechanisms. Prior to version 2026.6.4, mise's trust feature correctly gates configuration files such as mise.toml and .tool-versions through the trust_check function, but fails to apply similar protections to task-include directories. When a directory contains a task-include directory structure like mise-tasks/ or .mise/tasks/ without a corresponding configuration file, mise defaults to loading these include paths and renders each task's tera template fields.
The technical implementation of this vulnerability stems from the fact that the tera template environment within mise includes an exec() function registration that allows arbitrary command execution. When tasks are rendered and their tera fields processed, any {{ exec(command='...') }} expressions found in these fields execute immediately during task listing operations. This creates a critical security gap where malicious code can be executed simply by navigating to a directory containing such task files, without requiring explicit user interaction beyond basic directory traversal.
The operational impact of this vulnerability is significant as it enables remote code execution through simple directory navigation and command listing operations. Attackers need only clone a repository containing malicious task files and execute commands like mise tasks, mise task ls, mise run, or trigger tab completion in shells that utilize mise for task management. The vulnerability is particularly dangerous because it requires no user interaction beyond basic shell operations, and the trust prompt never appears since no configuration file exists to trigger the gating mechanism. This aligns with CWE-78, which describes improper neutralization of special elements used in OS commands, and represents a privilege escalation vector through untrusted data processing.
This vulnerability directly relates to ATT&CK technique T1059.001 for command and script interpreter execution, specifically through the use of shell command execution within template rendering contexts. The attack surface is expanded by the fact that shell completion systems often trigger mise task listing operations automatically, creating an additional vector for exploitation. Mitigation strategies should focus on implementing trust validation for all task inclusion paths regardless of configuration file presence, ensuring that any tera template processing involving external commands requires explicit user approval or proper authentication mechanisms. The vulnerability is resolved in mise version 2026.6.4 through enhanced trust checking that applies to all task loading operations, preventing automatic execution of potentially malicious commands during task listing and completion operations.
The fix implemented in version 2026.6.4 addresses the root cause by extending trust validation beyond configuration files to include all task inclusion directories and their contents. This change ensures that any template processing involving external command execution requires proper trust verification before proceeding, eliminating the automatic execution of arbitrary commands during simple task listing operations. The solution aligns with security best practices for template engines and input validation, preventing the exploitation scenario where untrusted data from task files could be processed without proper safeguards.