A repository trust dialog is supposed to mark the boundary between looking at untrusted code and allowing a development tool to interact with it. The Mistral Vibe security vulnerability disclosed on November 4, 2026, showed that boundary could occur too late. A specially crafted Git repository could cause commands to run as Mistral Vibe initialized a session—before the coding agent displayed its normal repository trust prompt.
The disclosure covered three related security flaws involving repository-local Git configuration, Git filter-driver behavior, and executable resolution on Windows. Together, they created paths to Mistral Vibe RCE, or remote code execution in the practical sense that an attacker could prepare a repository and wait for a developer to open it. The flaws were patched, and the disclosure does not establish that every installation was vulnerable at the same time, much less that every Mistral Vibe user was compromised.
The incident nevertheless illustrates an important lesson for AI coding agent security: an unfamiliar repository is not merely a collection of source files. It can include metadata and configuration capable of influencing Git, language tooling, hooks, filters, build systems, and the agent examining it.
What the Mistral Vibe disclosure established
According to the November 4 disclosure summary and the VulnCheck and GitHub records linked from it, researchers found three ways in which startup processing could cross the intended trust boundary. The central issue was sequencing: Mistral Vibe performed operations influenced by repository-controlled data before asking the user whether the repository should be trusted.
The reported vulnerability set is associated with CVE-2026-122135. The original advisories classify the code-execution impact as serious because successful exploitation could run commands with the privileges of the developer who launched Mistral Vibe. Exploitation still required a user to obtain and open a malicious Git repository; this was not evidence of an unauthenticated attack against every internet-accessible installation.
The affected range consists of Mistral Vibe releases predating the security fixes published for the November 4 disclosure. Users should rely on the exact affected and fixed version ranges shown in the live GitHub advisories because release channels and backported packages can differ. The project’s GitHub advisory record for CVE-2026-122135 is the appropriate source for checking whether a particular installed build contains the fixes. Current patched releases are not affected by the original behavior described in the advisories.
How a malicious Git repository could execute code
The flaws did not depend on persuading the model to follow hostile prose in a README file. Instead, they exploited conventional software behavior occurring around the agent. Mistral Vibe invoked or relied on Git while preparing repository context, and Git’s behavior can be changed by configuration and attributes associated with a repository.
1. Malicious repository-local Git configuration
Git supports configuration at several scopes, including system, user, and repository level. Repository-specific settings normally live in .git/config. That file is not part of an ordinary commit, but it can still be present in a repository directory delivered as an archive, copied workspace, prepared development image, or otherwise preconstructed working tree.
The first flaw arose because startup logic interacted with Git before Mistral Vibe had completed its trust decision. If the repository’s local configuration redirected a Git operation toward an attacker-controlled command or helper, merely initializing the session could cause that command to execute.
This is a form of Git configuration code execution. The dangerous input is not necessarily visible in the source tree presented by a hosting website. A developer reviewing tracked files remotely might see harmless code while overlooking configuration stored under the hidden .git directory.
The broader design mistake was treating the trust prompt as protection while allowing trust-sensitive initialization to happen first. A warning cannot protect an operation that has already taken place.
2. Git filter-driver behavior
The second route involved Git filters. A repository can use .gitattributes to associate files or path patterns with a named filter. The corresponding filter driver is defined through Git configuration and may specify external commands for clean or smudge processing.
Filters have legitimate uses. Projects employ them for line-ending conversion, large-file handling, encryption workflows, generated content, and other transformations. But an external filter is also executable behavior. When a tool asks Git to materialize, inspect, convert, or otherwise process a matching file, Git may launch the configured program.
That distinction matters because .gitattributes is normally tracked and can therefore travel with a repository. A malicious repository combining crafted attributes with hostile local configuration could arrange for an apparently routine startup query to activate a filter driver. If Mistral Vibe caused Git to process the affected path before approval, the filter command could run before the user saw the repository trust prompt.
This was not simply a case of a dangerous script sitting in the project and waiting for a developer to execute it. The interaction between attributes, configuration, and automatic startup behavior provided the trigger.
3. Windows executable search-path handling
The third flaw was specific to Windows executable resolution. When software starts another program by name rather than by a validated absolute path, Windows search behavior can allow an executable in an attacker-influenced directory to be selected ahead of the intended trusted binary.
A malicious repository could include a program named to impersonate a command Mistral Vibe expected to launch during startup. If the affected version searched the repository or current working directory before the trusted installation location, it could execute the repository’s program. That produced another route to pre-approval command execution.
The fix required more than adding another warning. Secure process creation should use an explicitly resolved, trusted executable and a controlled environment. The working directory should never be assumed safe merely because the program is about to ask whether the user trusts it.
Why pre-prompt execution is especially dangerous
Developers often use coding agents precisely when they do not yet understand a project. They may ask an agent to summarize an open-source package, investigate a bug in a customer-supplied reproduction, evaluate a job candidate’s exercise, or inspect a proof-of-concept repository shared in a security report.
That workflow creates an inversion of traditional trust assumptions. The developer opens the tool to help determine whether the repository is safe and relevant, but the tool may inspect the repository using components whose behavior the repository can influence.
If exploitation succeeded, commands would run with the developer’s account privileges. Depending on that account and environment, accessible assets could include source code, local files, package-registry tokens, cloud credentials, SSH keys, signing material, browser sessions, or secrets exposed through environment variables. Those are possible consequences of code execution, not evidence that the disclosed flaws were used to steal such data.
The vulnerability also demonstrates why sandboxing and least privilege matter. A trust prompt is a useful control, but it is only one layer. It cannot compensate for unsafe startup actions, broad filesystem access, inherited credentials, or ambiguous executable lookup.
Repository RCE is not the same as prompt injection
The Protec has previously examined the Claude Code extension backdoor and attacks based on AI-agent prompt injection. Those stories belong to the same wider discussion about trusting AI developer tools, but the mechanisms should not be conflated.
Prompt injection attempts to manipulate a model through instructions embedded in content. A hostile README, comment, issue, or web page might tell an agent to ignore its policies, reveal information, or invoke a tool. Success depends on how the model interprets the content and what tools it is permitted to use.
The Mistral Vibe flaws operated below that semantic layer. The repository influenced Git and operating-system process behavior during session initialization. No clever natural-language instruction was required. Even a model that perfectly rejected malicious prompts could still be exposed if its host application ran an attacker-selected executable first.
The Claude Code extension backdoor scenario is also distinct. A compromised extension or distribution channel inserts malicious behavior into trusted tooling. Here, the risk originated in an untrusted repository interacting with legitimate application functionality. The common lesson is that an AI agent’s security boundary includes its extensions, subprocesses, configuration files, repository metadata, and operating-system environment—not just the model.
Practical checklist for developers
- Update Mistral Vibe. Install a release identified as fixed in the project’s current GitHub advisory and verify the version actually used in your shell, editor, container, or CI environment. Remove stale copies that may appear earlier in the executable path.
- Inspect unfamiliar repositories before launching an agent. Use an isolated environment to examine the directory structure, including hidden files. Do not assume a repository is safe because its visible source files look ordinary.
- Review
.git/config. Look for unexpected command-bearing settings, helpers, filters, aliases, hooks paths, external diff programs, or other values that can invoke processes. A normal clone creates local configuration, but copied or archived repositories may arrive with hostile metadata. - Review
.gitattributes. Identify custom filters and determine where their drivers are configured. Treat unexplained filter names or attributes affecting many files as reasons for further investigation. - Use a clean clone when possible. Cloning tracked content into a fresh directory is generally safer than opening a complete working tree supplied by an unknown party, although it does not make all repository-driven behavior harmless.
- Isolate high-risk reviews. Open unknown projects in a disposable virtual machine, container, or restricted account without production credentials. Isolation should limit filesystem, network, keychain, and environment-variable access.
- Check Windows command resolution. Remove unexpected executables from repository roots and confirm which binary the shell or application will launch. Security-sensitive tools should use trusted absolute paths.
- Do not overestimate the repository trust prompt. Confirm what occurs before the dialog appears. A prompt protects only the actions that the application actually postpones until after approval.
What maintainers of AI developer tools should learn
Applications should treat all repository-derived information as hostile until trust is established. Pre-trust initialization should avoid commands whose behavior can be modified by repository configuration, attributes, environment variables, working-directory contents, or project-specific tool files.
Where preliminary inspection is unavoidable, tools should use non-executing parsers, ignore repository-local configuration, disable external filters, resolve executables through trusted absolute paths, and run in a tightly restricted sandbox. The application should also document exactly what the trust decision covers.
Regression testing is equally important. Tests should include repositories containing hostile local Git settings, custom attributes, executable name collisions, symlinks, unusual worktrees, submodules, and platform-specific path cases. The relevant question is not simply whether a repository can contain executable code. It is whether any component can execute that code before the user has consented.
FAQ
Was every Mistral Vibe installation compromised?
No. The disclosure identified exploitable behavior in affected versions; it did not show that every installation was attacked or compromised. Exploitation required a developer to open a specially prepared repository under the conditions described by the advisories.
Are current Mistral Vibe releases still vulnerable?
The reported flaws were patched. Developers should compare their installed build with the fixed release range in the live GitHub advisory, since old binaries, editor integrations, containers, and cached environments can remain in use after a system-wide update.
Would rejecting the repository trust prompt prevent exploitation?
Not reliably on an affected version. The core problem was that command execution could occur during startup before the prompt appeared. Rejecting the prompt afterward could not undo an action that had already run.
Can a normal Git clone contain a hostile .git/config?
A standard clone does not obtain another repository’s local .git/config as a tracked file. However, developers also receive repositories as archives, copied workspaces, virtual-machine images, development containers, and prepared directories. Tracked .gitattributes can also influence Git behavior when paired with relevant configuration.
Is this vulnerability a form of AI prompt injection?
No. Prompt injection manipulates model behavior through hostile instructions. This vulnerability used repository and operating-system mechanisms to trigger commands before approval. Both threaten AI-assisted development, but they require different defenses.
The trust boundary must come before initialization
CVE-2026-122135 is a useful warning for the entire AI coding ecosystem. Developers increasingly rely on agents to examine code they have not reviewed, which makes the safety of the first few startup operations critical. Repository metadata, Git filters, and executable search paths must be considered active inputs—not harmless background details.
Mistral Vibe’s fixes address the disclosed paths, so the lesson is not to avoid the tool or assume ongoing compromise. It is to update promptly, inspect unusual repository metadata, isolate risky reviews, and demand that trust decisions occur before any repository-influenced command can run.
