mise Security: Entering a Repo Folder Can Run an Attacker's Command — Keep It Updated

mise, the development-environment manager used by developers worldwide, carried a flaw before version 2026.6.4: an attacker's commands could run on your own machine just by entering a crafted project folder, or even by tab-completing a command. The two representative cases are CVE-2026-33646 (fixed in 2026.3.10) and CVE-2026-55441 (fixed in 2026.6.4), with CVSS severity reaching 9.6 out of 10 (Critical). 2026.6.4 or later clears both. That said, problems in the same family — slipping past the "trust" check — have kept turning up since, so if you are installing or still using mise, the safe move is to stay on the latest version (2026.7.12 as of 2026-07-23). The latest release also adds a new defense, a "Safe mode" that treats untrusted config with caution across the board.

mise has a safeguard called trust so it won't run config files it doesn't trust. But starting with the two flaws here, holes that slip past that check and run commands the user never approved have kept surfacing — a weakness 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, which version is safe, 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. These two are the headline examples of the "slips past the trust check" problem, but not the only ones — advisories in the same family have continued since, which we summarize in a later section.

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. What follows is, in short, holes punched in that foundation — and not just once, but as a pattern of trust-check bypasses found again and again. The maintainer has kept responding: the latest release as of 2026-07-23, 2026.7.12, introduces a new "Safe mode" that treats untrusted config with caution across the board, part of rebuilding 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.

Not just these two: trust-bypass advisories keep coming

Beyond these two, mise has a string of advisories in the same "bypasses the check" family. Examples include CVE-2026-55448 (CVSS 6.3, Moderate; fixed in 2026.6.4), where a local credential-fetch command runs without the check, and GHSA-436v-8fw5-4mj8 (High), where part of the settings skips the check. A different kind of hole — the install script not setting file ownership correctly, which could let someone seize administrator rights (the top-level privileges a regular user normally can't use) — was fixed in 2026.7.1 (GHSA-9mm4-fgvc-x7rp, CVSS 6.7, Moderate). None scores as high as 9.6, but the fact that holes around the trust check keep appearing is a reason to follow the latest version rather than stopping at any single one.

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. As noted above, though, even 2026.6.4+ has since seen other trust-check advisories and an install-time privilege-escalation hole (fixed in 2026.7.1), so while you're auditing, it is safest to bring machines up to the latest version (2026.7.12 as of 2026-07-23). 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. The two flaws in this article close at 2026.6.4 or later, but since then advisories around the trust check and an install-time privilege-escalation hole have kept coming, so if you update now, it is safest to reach the latest version (2026.7.12 as of 2026-07-23). No workaround is offered, so updating is the root fix. The latest release also adds a "Safe mode" that treats untrusted config with caution across the board. 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. These two close at 2026.6.4 or later, but holes around the trust check have kept turning up since, so if you use mise now, staying on the latest version (2026.7.12 as of 2026-07-23, which also adds a "Safe mode" that guards untrusted config) is the surest choice. 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; latest 2026.7.12 adds Safe mode)
• ▸jdx/mise - Security Advisories (CVE-2026-55448 and later advisories)
• ▸mise docs - mise trust