Mistral Vibe Ran a Repository's Git Hooks Before Trust Checks, Enabling RCE

Mistral has fixed a remote-code-execution flaw in its Vibe coding agent that let a malicious repository run shell commands on a developer's machine through the very path meant to keep that repository contained. The bug is tracked as CVE-2026-93993. It affects Mistral Vibe before version 2.25.5 and scores 8.8 out of 10 (High) on the CVSS 3.1 scale. Mistral published v2.25.5 on September 18, 2026, roughly twelve minutes after the public GitHub issue describing the flaw was closed.

Related reading: A Zero-Click Flaw Let Malicious Plugins Run Code in Four Major AI Coding Agents · AI-Found Rejetto HFS Authentication Bypass Draws Exploitation Attempts.

The vulnerable code ran a repository's Git hooks during worktree creation, before the agent had decided whether that repository could be trusted. Git executes a post-checkout hook automatically when a worktree is created, so a repository could carry a hook that ran attacker commands with the privileges of the user who launched Vibe. The user did not approve anything, because the approval prompt that these tools present as their safety boundary appeared only after the payload had already executed.

The order of operations was the vulnerability

Vibe is Mistral's open-source, terminal-native coding agent, distributed as the PyPI package mistral-vibe. It supports a --worktree flag, which creates a separate linked working tree so that the agent's edits do not touch the user's main checkout. That flag is the option a careful user picks precisely to keep an untrusted repository at arm's length.

The reporter who filed GitHub issue #996 traced the problem to the entry point. In vibe/cli/entrypoint.py, the agent calls prepare_auto_worktree_session() or prepare_worktree_session() when --worktree is set. That call makes Git create the worktree and fire post-checkout. The trust mechanism is initialized later, in init_harness_files_manager(). The result is a window in which repository-controlled code runs before any trust check exists to stop it.

The issue, titled "[Security] Remote Code Execution via worktree creation (git hook execution)," included a complete, copy-pasteable Bash script that builds a malicious repository: it initializes a repo, makes an initial commit, and installs a .git/hooks/post-checkout that runs id > /tmp/POC. The reporter also stated the severity assessment directly in the issue, listing the CVSS 3.1 vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H and the score of 8.8. The issue was filed against v2.24.1.

To see why the ordering mattered, it helps to separate the two Git concepts at play. A worktree is a second working directory linked to the same repository, and creating one checks out files and therefore triggers checkout-related hooks. A Git hook is a script stored inside the repository under .git/hooks/, and post-checkout runs automatically after a checkout or worktree creation. A hook is ordinary repository content, so an attacker who controls the repository controls the script. No configuration or approval is normally involved, because the user has already asked Git to check the code out.

The attack still requires a user to point the agent at a hostile repository, for example by cloning or importing it and then running Vibe there. The CVSS vector reflects that: network attack vector with user interaction required (UI:R). In practice the delivery is social engineering, a typosquatted package, or any repository a developer is asked to "quickly take a look at." That is a low bar for a tool designed to open and reason about unfamiliar code.

A public proof of concept sat for over five weeks

The disclosure timeline is unusual. According to GitHub's own API, issue #996 was created on August 11, 2026 at 22:12 UTC by a user going by therealcoiffeur, was labelled security, bug, CLI, and Security and Compliance, and was assigned to a maintainer. It carried the proof of concept in the open and received zero comments. It was closed on September 18, 2026 at 10:57 UTC. Mistral published v2.25.5 at 11:09 UTC that same day, about twelve minutes later, from commit c069ffa.

The issue was open for just over 37 days. The security news and analysis site agenccy.ai framed the same gap as 37 days and argued the episode has been misread as a coordinated disclosure that worked, when the report was neither coordinated nor private. That framing is analysis rather than a vendor statement, but the underlying timestamps are public.

The fix landed as a single line in a long "Fixed" list. The v2.25.5 notes say: "Creating or cleaning up a worktree no longer runs the repository's own git hooks (such as post-checkout) or its fsmonitor command." A related item in the same release added "vulnerability disclosure guidance and private reporting instructions in SECURITY.md," which is itself a signal that a private reporting channel had been missing while the report sat in public. The remote-code-execution fix is not called out as a security fix, and as of September 21 Mistral had not published a standalone advisory naming the CVE, so a user skimming the changelog would find no obvious reason to update urgently.

The disclosure path raises a familiar trade-off. A public, uncoordinated report with a working exploit can force a vendor's hand and warn defenders, but it also hands attackers a ready-made tool and can leave users exposed for as long as the report is ignored. Here the proof of concept was benign, writing the output of id to a file, but the same technique substitutes any command. A maintainer's silence on a public security issue for more than five weeks is the part of the story that will interest other projects shipping agentic tools.

Where the 8.8 came from

The CVE was assigned by VulnCheck, not by Mistral, and VulnCheck's advisory credits Mathieu Farrell as the finder. The public issue was opened by therealcoiffeur; the public record does not state on its face whether the two are the same person, so the credit and the report should be treated as separate facts.

The CVE record, published to CVE.org on September 19 at 22:58 UTC and to NVD at 23:17 UTC, carries two scores. The CVSS 3.1 base score is 8.8 (High) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, and a CVSS 4.0 base score of 8.6 (High). The weakness is classified as CWE-829, "Inclusion of Functionality from Untrusted Control Sphere." The affected package is pkg:pypi/mistral-vibe, versions 0 up to but not including 2.25.5. NVD listed the record with a status of "Received" as of September 21, meaning it had not yet been through NVD's own enrichment.

Both scores come from VulnCheck, and per agenccy.ai's analysis, the 8.8 is the vector the reporter wrote in the public issue, carried into the CVE by the CNA. No vendor-supplied severity appears in the record. That matters for how the number gets read: it is a credible third-party assessment, not Mistral's own, and it should be treated accordingly.

Why this keeps happening, and how to respond

Coding agents execute untrusted repository content by design. They read files, install dependencies, run build and test commands, and often touch Git. That makes the boundary between "code we are inspecting" and "code we are running" the whole security model, and it is easy to get the order wrong. Any step that causes Git, a package manager, or a build script to execute before the trust decision is a potential pre-approval execution path. Git hooks are a classic example, because they run automatically and are stored inside the repository itself.

Vibe is not the only agent to have run into this. A separate flaw disclosed in September 2026, tracked as Plugin4Shell, let a trusted plugin run attacker code across the plugin systems of Claude Code, OpenAI's Codex, GitHub Copilot and Google's Gemini CLI. The mechanism there was a SHA-pinning bypass rather than a Git hook, but the underlying question is the same for every agent that opens third-party code: what runs before the trust decision, and who controls it? Agents that manage Git themselves inherit Git's execution surface, including hooks, filters, external diff drivers and file-monitor commands. The v2.25.5 notes show that Mistral had to disable several of those paths, including the checkout hook, when it cleaned up worktree handling.

The response for users is straightforward. Update Vibe to 2.25.5 or later, which stops worktree creation and cleanup from running repository hooks. Treat the trust prompt as meaningful only if it happens before execution, rather than only what happens after it. Be cautious with repositories from sources you do not control even on patched versions, because new order-of-operations bugs are a recurring pattern rather than a one-off. Where the workflow allows it, run the agent in a container or a throwaway virtual machine with limited credentials, so that a hook that does fire cannot reach the developer's real SSH keys, cloud tokens or source tree. Teams can also set core.hooksPath to an empty directory outside the repository as a defence-in-depth measure, though that is a mitigation for the class of bug, not a substitute for updating. For maintainers, the lesson is to review what a coding agent does at startup, before any approval step, rather than only what it does inside a session.

What to watch now: whether Mistral publishes its own advisory with a vendor severity score, whether the still-open fix pull request #1032, titled "fix(git): disable repository hooks during worktree creation," is merged or superseded by the release commit, and whether other agent vendors audit their own hook and checkout paths. The credit line and the changelog bullet are already public. The open question is how quickly the rest of the category checks the same sequence.

Cover: Mistral AI co-founder and CEO Arthur Mensch at Techarena 2026, by Jan2342342423 (CC0 1.0) via Wikimedia Commons, cropped 16:9.