CVE-2026-35533: Arbitrary Code Execution via Trust Bypass in mise Configuration Parsing

The mise development tool manager relies on configuration files to orchestrate local development environments. This vulnerability, tracked as CVE-2026-35533, manifests in versions 2026.2.18 through 2026.4.5 due to a logic flaw in the configuration bootstrapping phase.

The root cause is an improper access control implementation (CWE-284) that fails to isolate security-sensitive directives from untrusted configuration sources. When mise encounters a local .mise.toml file, it processes the contents before validating the file's origin against the established trust boundary.

This architectural oversight allows an attacker to manipulate the trust evaluation process itself. By redefining the trusted_config_paths setting within the local file, the malicious configuration grants itself trusted status, enabling the execution of arbitrary commands.

The vulnerability stems from the specific execution order during the configuration loading phase. The Settings::try_get() function is responsible for preloading settings from local, project-level .mise.toml files.

During this preload phase, the parse_settings_file() function deserializes the TOML payload without first verifying if the file resides in a trusted directory. This creates an initialization race condition where settings used to determine trust are loaded from untrusted sources.

The trust_check() function subsequently evaluates the newly instantiated Settings object. By reading settings.trusted_config_paths(), the system allows the untrusted configuration file to dictate the global trust policy. The system evaluates the attacker's path against the attacker's own provided allowlist.

The vulnerability is evident in the source file src/config/config_file/mod.rs, where the trust verification loop reads directly from the globally accessible but unverified Settings object. The iteration over settings.trusted_config_paths() unconditionally accepts paths provided by the local .mise.toml.

// Vulnerable code path evaluating trust
let settings = Settings::get();
for p in settings.trusted_config_paths() {
    if canonicalized_path.starts_with(p) {
        add_trusted(canonicalized_path.to_path_buf());
        return true;
    }
}

If the local configuration supplies trusted_config_paths = ["/"], the canonicalized_path.starts_with(p) condition evaluates to true for any file on the filesystem. This guarantees the untrusted file is added to the trusted list.

The patch introduced in version 2026.4.6 resolves this by explicitly filtering security-sensitive configuration keys during the parsing phase. The parse_settings_file function now uses an origin check via config::is_global_config(path) to prevent local files from overriding global settings.

// Patched settings parser
pub fn parse_settings_file(path: &Path) -> Result<SettingsPartial> {
    let raw = file::read_to_string(path)?;
    let settings_file: SettingsFile = toml::from_str(&raw)?;
    let mut settings = settings_file.settings;
 
    // Ensure local/project configs cannot override security settings
    if !config::is_global_config(path) {
        settings.yes = None;
        settings.ci = None;
        settings.trusted_config_paths = None;
        settings.paranoid = None;
    }
 
    Ok(settings)
}

The attack sequence relies on the victim downloading or cloning a repository containing the malicious configuration file. The following diagram illustrates the execution flow from the malicious file to the compromised shell.

The exploit requires no specialized tools beyond a text editor and an understanding of the TOML syntax used by mise. The attacker relies entirely on the built-in hooks and task execution features of the vulnerable software.

Exploitation requires an attacker to convince a victim to interact with a directory containing a maliciously crafted .mise.toml file. This interaction typically occurs when a developer clones an untrusted git repository and navigates into it while their shell is configured to use mise hooks.

The attacker constructs a configuration file containing two primary sections. The [settings] block redefines trusted_config_paths to include the filesystem root (/), bypassing the prompt. The [env] block defines the payload script.

[settings]
trusted_config_paths = ["/"]
 
[env]
_.source = ["./poc.sh"]

When the victim's shell executes a mise hook, such as mise hook-env -s bash --force, the tool processes the local configuration. It reads the manipulated trust settings, trusts the file, and blindly executes the directives in _.source, achieving arbitrary code execution.

#!/usr/bin/env bash
echo "Vulnerability Executed" > /tmp/mise-proof.txt

The vulnerability yields arbitrary code execution with the privileges of the user running mise. This grants the attacker full access to the victim's local files, environment variables, SSH keys, and active authentication tokens.

The CVSS v3.1 vector evaluates to 7.8 (High) via CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H. The complexity is marked High (AC:H) because the exploit relies on the victim navigating to the specific directory while shell hooks are active.

While categorized as a local attack vector (AV:L), the delivery mechanism frequently involves remote untrusted repositories. The scope change (S:C) reflects the transition from a configuration parsing vulnerability into shell-level command execution context.

The primary remediation strategy is upgrading the mise binary to version 2026.4.6 or later. This release permanently removes the ability for local configuration files to override global security settings by nullifying sensitive fields during parsing.

Users can upgrade their installation by executing the command mise self-update. Following the update, the version should be verified by running mise --version to ensure the patch applied successfully.

As a defense-in-depth measure, developers should audit their global ~/.config/mise/config.toml file to ensure no unauthorized paths are persistently trusted. Strict caution is advised when cloning unfamiliar repositories, regardless of the active toolchain.