Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Untrusted local .mise.toml [settings] can set the shell interpreter args (unix/windows defaultinline / defaultfile shellargs), yielding arbitrary command execution, because those command-interpreter settings were not added to the globalonly denylist the CVE-2026-55448 fix relies on. Code execution from an untrusted repository with no trust prompt for the malicious file, on par with the patched CVE. Confirmed at HEAD 7160170206782fdd3ef287c8302369e32152fb71. The defect CVE-2026-55448 and CVE-2026-35533 fixed the fact that a local project [settings] table is harvested by the settings preloader independent of the trust store (an untrusted .mise.toml sets settings without the user ever trusting it). The remediation is a per-field globalonly denylist: settings marked globalonly are stripped from non-global config. The maintainers marked the command-execution fields they knew about (the three forge credentialcommand values) but did not mark the four shell-interpreter-args settings,…
Recommended action: Upgrade to 2026.7.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
`mise` loads `github.credential_command` from local project config before any trust decision, then executes that value with `sh -c` when resolving a GitHub token. An attacker who can place a `.mise.toml` in a repository can execute arbitrary shell commands when the victim runs a GitHub-related mise command and no higher-priority GitHub token environment variable is set. The current command-execution path is `github.credential_command`. I confirmed in Docker that the setting is exploitable on `v2026.3.15` and `v2026.3.17`, while `v2026.3.14` rejects it as an unknown field. This report does not depend on the separate trust-bypass issue because the sink is reached directly from `[settings.github]`. Details The vulnerable load order is: 1. `Settings::try_get()` preloads settings from local config files. 2.…
Recommended action: Upgrade to 2026.6.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
mise's trust feature gates config files (mise.toml, .tool-versions) through trustcheck, 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 Details Trust is enforced only inside config-file parsing: - src/config/configfile/misetoml.rs:276 — MiseToml::fromstr → trustcheck(path)? - src/config/configfile/toolversions.rs:62 — .tool-versions parser → trustcheck(&path)? -…
Recommended action: Upgrade to 2026.6.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The mise HTTP backend builds its install symlink destination from the raw resolved version string for non-latest versions. Normal tool install paths use the sanitized version pathname, but the HTTP backend's symlink path uses the raw value. On Unix-like systems, if that version is an absolute path, PathBuf::join discards the intended mise installs root. A repository-controlled .tool-versions file can therefore make mise install create a symlink outside the mise install tree. With binpath, the same issue can place an executable symlink under an attacker-selected absolute prefix, such as a developer-tool prefix that is later added to PATH. The reproducer below also models a CI/developer workflow where a later step executes a preexisting trusted command from a user-local PATH prefix. The absolute-version HTTP entry replaces that command with a symlink to downloaded HTTP content. A non-absolute version control does not replace the trusted PATH command. Affected Code In…
Recommended action: Upgrade to 2026.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Mise processes .tool-versions files through the Tera template engine during parsing, with the exec() function registered, enabling arbitrary command execution. Unlike .mise.toml files, .tool-versions files are not subject to trust verification in non-paranoid mode. This means an attacker can place a malicious .tool-versions file in a git repository, and when a victim with mise activated cds into the directory, arbitrary commands execute without any trust prompt. Vulnerability Details Vulnerable Code File: src/config/configfile/toolversions.rs, lines 60-63 File: src/tera.rs, lines 385-391 File: src/tera.rs, lines 394-452 -- teraexec passes the command argument to a shell for execution with no restrictions. File: src/config/configfile/mod.rs, lines 272-287 Attack Vector 1. An attacker creates a .tool-versions file in a git repository containing Tera template syntax with the exec() function. 2. The victim clones the repository and has mise activated in their shell (via eval…
Recommended action: Upgrade to 2026.3.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 trustedconfigpaths = ["/"]. 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 trustedconfigpaths path. Details The vulnerable load order is: 1. Settings::tryget() preloads local settings files. 2. parsesettingsfile() returns settingsfile.settings without checking whether the file is trusted. 3. trustcheck() later consults those already-loaded settings. The main trust-bypass path is…
Recommended action: Upgrade to 2026.6.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.