Critical mise flaws CVE-2026-33646/55441: cd into a repo, code runs

Two vulnerabilities have been disclosed back to back in mise, the development-environment manager used by developers worldwide, that let an attacker's commands run on your own machine just by entering a crafted project folder, or even by tab-completing a command (CVE-2026-33646 and CVE-2026-55441). The CVSS severity reaches 9.6 out of 10 (Critical). Fixes ship in 2026.3.10 and 2026.6.4.

mise has a safeguard called trust so it won't run config files it doesn't trust. Both of these flaws, however, slip past that check and run commands the user never approved — a hole in the safeguard itself. For anyone who writes code, cloning someone else's repository (a project's storage) and stepping inside is everyday work. This article walks through what happens, what action triggers it, and what to do now.

Overview of the two flaws

Here are the essentials at a glance. In both cases the starting point is the same: a developer pulls down a repository that contains a malicious config file. You are not attacked one-sidedly over the internet; the trigger is an action you never even think about — entering a folder, listing tasks, or tab-completing.

The scores stop at 9.6 and 8.6 rather than a perfect 10.0 because the attack needs a small user action (UI:R) — entering a folder, listing tasks. Still, cloning someone else's code and inspecting it is a developer's daily job, so the precondition is met easily. Both were published as security advisories (GHSA) on the project's GitHub, with fixed releases available.

Who targets this, and why

What makes these two scary is that the attack happens before you ever "open and run" a suspicious file. The instant you step into a folder to read what's inside, it can already be too late. The people who go after this are attackers who scatter malicious repositories disguised as handy tools or quick fixes, supply-chain attackers who slip fake "fix" pull requests into popular projects, and initial-access brokers who use a developer's machine as a stepping stone into their employer's internal systems. To them, a developer's machine is a treasure chest full of master keys to production servers and source code.

The method goes like this. The attacker hides one inconspicuous config file inside an ordinary-looking repository, and when the developer clones it and steps in — or merely lists its tasks — runs the command they prepared on that person's machine. What gets stolen is the valuable material sitting on a developer's computer: SSH private keys (the keys to log into servers), cloud credentials, half-written source code, and signing keys.

The damage doesn't stop with the individual. With cloud credentials in hand, the attacker walks into production and internal systems posing as a legitimate user. Stolen keys get resold; buyers extract source code, poison the build pipeline, and cascade the breach into the partners and customers who consume the resulting artifacts. Cleaning up falls on the developer who used the tool and on their team and IT department — rotating keys across everything affected, explaining the incident to partners, and rebuilding lost trust. The shortest way to cut off the entry point is simply keeping the tool up to date.

What mise is, and why "trust" matters

mise is a command-line tool developed mainly by Jeff Dickey (@jdxcode). It automatically switches the programming-language versions a project needs (Node.js, Python, and so on) and bundles management of common chores (tasks) and environment variables. It spread fast as a replacement for the long-standing tool asdf, and its GitHub stars — a measure of attention — now exceed 30,000. Many developers run it built into their terminal every day.

The key point is that mise lives in your terminal and reads a folder's config files the moment you move into that folder. Behind the convenience of versions switching automatically as you change projects, this creates a state where config files get interpreted just by entering the folder.

That's why mise has a safeguard called trust: config files in an unfamiliar folder are not executed until the user explicitly says "I trust this file" via mise trust. The official documentation describes this as the foundation of mise's safety. These two flaws are, in short, holes punched in that foundation.

Looking at the two flaws individually

CVE-2026-33646: a command runs just by entering the folder (CVSS 9.6)

This is the more severe of the two. mise processes .tool-versions — a file that records language versions — through a templating feature called "Tera." The problem is that the processing left a command-execution instruction (exec()) available, and .tool-versions was excluded from the trust check described above. The published advisory states plainly that, "unlike .mise.toml, .tool-versions files are not subject to trust verification."

So the attacker only has to prepare a repository with a doctored .tool-versions. The moment a developer with mise enabled does a cd into that folder, the planted command runs with that user's privileges — no prompt, no warning. The severity is CVSS 9.6 (Critical), vector AV:N/AC:L/PR:N/UI:R. It affects all versions before 2026.3.10 and is fixed in 2026.3.10.

CVE-2026-55441: fires even in a config-less repo, via task listing (CVSS 8.6)

The second flaw hid in the "tasks" mechanism that bundles routine work. mise lets you load task definitions from a separate "include file." But according to the advisory, while .mise.toml and .tool-versions go through the trust check, task include files were loaded on a path that never performs that check at all.

The nasty part is that it works even in an ordinary-looking repository with no visible config file. A developer who clones it and, wanting to see what work is available, simply lists the tasks or uses tab-completion triggers the planted command. The CVSS is 8.6 (High), and the flaw spans improper permission assignment (CWE-732) plus command injection (CWE-78) and code injection (CWE-94). It affects versions before 2026.6.4, fixed in 2026.6.4. Both belong to the same "slipping past the trust check" family, so fixing only one is not enough — you must reach the newer fixed version.

Quick check: are you affected?

Your risk depends on whether you use mise, which version, and whether you handle outside code. Find your situation in the table below. Check your version with mise --version.

The most dangerous pattern is handling other people's repositories or externally received code on an old mise. If your team or company distributes mise, audit every machine at once to confirm it is on 2026.6.4 or later. You can update via mise self-update or your OS package manager.

Is it being exploited?

Let's separate what we know from what we can't confirm yet.

What developers and organizations should check now

The top priority is updating mise to 2026.6.4 or later. Reaching the newer CVE's fixed version closes both. No workaround is offered, so updating is the only root fix. If you distribute it across an organization, audit each machine's version and confirm auto-update is enabled.

As a basic defense against this whole class of "runs just by opening or entering" flaws, make a habit of not casually cloning and stepping into untrusted repositories. In any environment where you handled unfamiliar code, check .tool-versions and task settings for entries you don't recognize, and consider rotating any related credentials (SSH keys, cloud keys). For other attacks aimed at developer tools, the takeover-grade pnpm flaws and the malicious-repo RCEs in the editor Zed are recent reminders. You can also quickly inspect the outside components your project pulls in with our free OSS vulnerability scanner. In an era when both attack and defense accelerate with AI, shoring up the developer's own footing only grows more important.

FAQ

Summary

CVE-2026-33646 and CVE-2026-55441 in the development-environment manager mise both slip past the safeguard that "untrusted config files are not run automatically." The first runs an attacker's command merely by entering a folder holding a .tool-versions file; the second, merely by listing or completing tasks — in both cases with the user's own privileges. The CVSS reaches 9.6, and while the attack needs the precondition of "bringing a malicious repository to your machine," that is easily met in the daily life of a developer who handles others' code. The fix is simple: update mise to 2026.6.4 or later. And it's worth revisiting the basic habit of not casually cloning and entering repositories you don't know.

References

• ▸NVD - CVE-2026-33646
• ▸NVD - CVE-2026-55441
• ▸GitLab Advisory - CVE-2026-33646 (.tool-versions / Tera templates)
• ▸GitLab Advisory - CVE-2026-55441 (task include files)
• ▸jdx/mise - Security Advisories (GHSA list)
• ▸jdx/mise - Releases (fixes 2026.3.10 / 2026.6.4)
• ▸mise docs - mise trust