Summary
A command injection vulnerability in mise allows an untrusted local repository to influence default shell interpreter arguments before the project receives trust approval. When a developer runs affected tasks or hooks that rely on those defaults, attacker-controlled commands may execute with the developer account's privileges.
A command injection vulnerability in mise allows an untrusted local repository to influence default shell interpreter arguments before the project receives trust approval. When a developer runs affected tasks or hooks that rely on those defaults, attacker-controlled commands may execute with the developer account's privileges.
Affected context
The issue occurs in mise's default non-safe operating mode when a local project's .mise.toml settings are loaded before trust approval. It affects workflows where trusted tasks, postinstall directives, template execution, or hooks rely on default shell behavior and do not specify an explicit shell. The relevant platform-specific shell argument settings were not treated as local-only values during trust filtering.
The issue occurs in mise's default non-safe operating mode when a local project's .mise.toml settings are loaded before trust approval. It affects workflows where trusted tasks, postinstall directives, template execution, or hooks rely on default shell behavior and do not specify an explicit shell. The relevant platform-specific shell argument settings were not treated as local-only values during trust filtering.
Exploit preconditions
- Attack surface: Local project configuration processed by mise
- Required access: Ability to place or modify a repository containing a
.mise.tomlfile - Trigger point: Execution of a trusted task, hook, postinstall directive, or template operation that uses the default shell
- Why exploitation is possible: Untrusted shell argument settings are applied before trust approval, and the trusted command is appended after attacker-controlled interpreter arguments
- Execution context: The developer account running mise
- Attack surface: Local project configuration processed by mise
- Required access: Ability to place or modify a repository containing a
.mise.tomlfile - Trigger point: Execution of a trusted task, hook, postinstall directive, or template operation that uses the default shell
- Why exploitation is possible: Untrusted shell argument settings are applied before trust approval, and the trusted command is appended after attacker-controlled interpreter arguments
- Execution context: The developer account running mise
Why this happens
The underlying bug is incomplete enforcement of trust boundaries for local configuration. mise removed only settings marked as global-only before using the configuration, while default shell argument settings that could alter interpreter behavior were not classified that way. As a result, untrusted data influenced command construction and execution, mapping primarily to CWE-78, Improper Neutralization of Special Elements used in an OS Command. The related CWE-284 reflects insufficient access-control enforcement around configuration trust and privilege-sensitive behavior.
The underlying bug is incomplete enforcement of trust boundaries for local configuration. mise removed only settings marked as global-only before using the configuration, while default shell argument settings that could alter interpreter behavior were not classified that way. As a result, untrusted data influenced command construction and execution, mapping primarily to CWE-78, Improper Neutralization of Special Elements used in an OS Command. The related CWE-284 reflects insufficient access-control enforcement around configuration trust and privilege-sensitive behavior.
Potential impact
- Arbitrary commands may execute with the developer account's privileges
- Local source code, credentials, or development secrets could be exposed
- Project files or generated artifacts could be modified
- Development environments may be used for persistence or lateral movement
- Build, testing, or release workflows could be disrupted or manipulated
- Arbitrary commands may execute with the developer account's privileges
- Local source code, credentials, or development secrets could be exposed
- Project files or generated artifacts could be modified
- Development environments may be used for persistence or lateral movement
- Build, testing, or release workflows could be disrupted or manipulated
General mitigation guidance
Mitigation generally focuses on enforcing trust boundaries before any
configuration can influence command construction.
Common defensive patterns include:
- Treating shell interpreter and execution-related settings as local-only or otherwise requiring explicit trust
- Using safe-by-default mode for repositories that are not fully controlled
- Restricting task, hook, postinstall, and template execution privileges
- Avoiding implicit shell selection where an explicit, constrained interpreter is suitable
- Reducing the trust placed in repository-controlled configuration and separating it from global policy
- Running development automation with least privilege and limited access to sensitive files and credentials
- Applying repository and configuration allowlists through organizational policy
Mitigation generally focuses on enforcing trust boundaries before any
configuration can influence command construction.
Common defensive patterns include:
- Treating shell interpreter and execution-related settings as local-only or otherwise requiring explicit trust
- Using safe-by-default mode for repositories that are not fully controlled
- Restricting task, hook, postinstall, and template execution privileges
- Avoiding implicit shell selection where an explicit, constrained interpreter is suitable
- Reducing the trust placed in repository-controlled configuration and separating it from global policy
- Running development automation with least privilege and limited access to sensitive files and credentials
- Applying repository and configuration allowlists through organizational policy
How teams detect issues like this
Detection can combine source review, configuration analysis, and runtime monitoring:
- Use static analysis to identify untrusted configuration values flowing into shell argument or command-construction APIs
- Review code paths that load local project settings before trust or approval checks
- Flag configuration fields capable of changing interpreters, hooks, postinstall behavior, or template execution
- Enforce policy checks that reject untrusted repositories containing execution-related settings
- Monitor development environments for unexpected child processes launched by mise or task runners
- Use automated code review and dependency-security tools to identify missing trust-boundary checks
Detection can combine source review, configuration analysis, and runtime monitoring:
- Use static analysis to identify untrusted configuration values flowing into shell argument or command-construction APIs
- Review code paths that load local project settings before trust or approval checks
- Flag configuration fields capable of changing interpreters, hooks, postinstall behavior, or template execution
- Enforce policy checks that reject untrusted repositories containing execution-related settings
- Monitor development environments for unexpected child processes launched by mise or task runners
- Use automated code review and dependency-security tools to identify missing trust-boundary checks
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
