CVE-2026-122135 in Mistral Vibe
Summary
by MITRE • 11/04/2026
Mistral Vibe before 3.0.3 contains a remote code execution vulnerability that allows attackers to run commands by abusing repository-configured gpg.program during project context collection. A crafted repository setting gpg.program and log.showSignature with a signed commit makes git log execute the attacker's program at session start, before any trust prompt.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The security flaw identified in Mistral Vibe prior to version 3.0.3 represents a critical remote code execution vulnerability rooted in the improper handling of Git configuration settings during project initialization. This issue specifically targets the interaction between the application and the underlying Git version control system, exploiting how environment variables and repository-specific configurations are processed when loading a workspace. The core technical deficiency lies in the way Mistral Vibe invokes git log commands to gather commit history and signature data for display within its interface. When a user opens or refreshes a project context that contains specific maliciously crafted Git configuration entries, the application fails to sanitize these inputs before passing them to the operating system shell or executing binary paths directly without sufficient validation of their integrity or origin.
The attack vector relies on manipulating two key Git configuration parameters: gpg.program and log.showSignature. An attacker can craft a repository where the gpg.program setting points to an arbitrary executable script or binary under the attacker's control, rather than a legitimate GnuPG installation. Simultaneously, by enabling log.showSignature in conjunction with commits that have been cryptographically signed using keys associated with this malicious configuration, the application is triggered to execute git log commands during session startup. Because Git attempts to verify these signatures upon request, it invokes the path specified in gpg.program. Crucially, this execution occurs before any user interaction or trust prompt can intervene, effectively bypassing standard security warnings that might otherwise alert a user to suspicious activity.
From an operational impact perspective, this vulnerability allows for arbitrary code execution with the privileges of the user running Mistral Vibe. Since the command is executed during session start, it happens automatically upon opening the affected project, requiring no further interaction from the victim beyond launching the application and selecting or loading the compromised repository. This makes the attack highly effective against developers who frequently switch between projects or clone repositories from untrusted sources such as public code hosting platforms. The consequences of successful exploitation include full compromise of the local development environment, potential theft of sensitive source code, installation of persistent backdoors, or use of the machine for further lateral movement within a corporate network.
This vulnerability aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command and CWE-94 Improper Control of Generation of Code. It also maps to MITRE ATT&CK technique T1059 Command and Scripting Interpreter, specifically through the abuse of system utilities like Git for initial access or execution. The lack of input validation on configuration-driven executable paths is a common pattern in applications that wrap complex command-line tools without implementing strict allow-lists or sandboxing mechanisms.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. Users should immediately upgrade to Mistral Vibe version 3.0.3 or later, where this issue has been addressed by the vendor through stricter validation of Git configuration values. In environments where upgrading is not instantly feasible, administrators can enforce security policies that restrict which users are allowed to modify global or local Git configurations such as gpg.program. Additionally, organizations should implement application whitelisting solutions that prevent unauthorized executables from running in development directories. Developers must also be educated on the risks of cloning repositories with modified configuration files and advised to audit their git config settings before opening projects sourced from external parties. Regular security audits of third-party dependencies and wrapper applications are essential to identify similar patterns where user-controlled data influences system-level command execution paths.