Mistral Vibe ejecutaba los hooks de Git de un repositorio antes de verificar la confianza y permitía ejecución remota de código

Mistral ha corregido un fallo de ejecución remota de código en su agente de programación Vibe que permitía a un repositorio malicioso ejecutar comandos de shell en la máquina del desarrollador precisamente a través de la ruta pensada para contener ese repositorio. El fallo se sigue como CVE-2026-93993. Afecta a Mistral Vibe anterior a la versión 2.25.5 y puntúa 8,8 sobre 10 (alta) en la escala CVSS 3.1. Mistral publicó la v2.25.5 el 18 de septiembre de 2026, unos doce minutos después de que se cerrara el issue público de GitHub que describía el fallo.

Lectura relacionada: Un fallo sin clics permitió a plugins maliciosos ejecutar código en cuatro grandes agentes de programación con IA · Un bypass de autenticación del Rejetto HFS hallado por IA atrae intentos de explotación.

El código vulnerable ejecutaba los hooks de Git de un repositorio durante la creación del worktree, antes de que el agente hubiera decidido si ese repositorio era de confianza. Git ejecuta automáticamente un hook post-checkout cuando se crea un worktree, así que un repositorio podía incluir un hook que ejecutara comandos del atacante con los privilegios del usuario que lanzó Vibe. El usuario no aprobó nada, porque el aviso de aprobación que estas herramientas presentan como su frontera de seguridad aparecía solo después de que el payload ya se hubiera ejecutado.

El orden de las operaciones era la vulnerabilidad

Vibe es el agente de programación de código abierto y nativo de terminal de Mistral, distribuido como el paquete PyPI mistral-vibe. Admite una opción --worktree, que crea un árbol de trabajo enlazado aparte para que las ediciones del agente no toquen el checkout principal del usuario. Esa opción es precisamente la que elige un usuario prudente para mantener a distancia un repositorio no confiable.

El informador que presentó el issue #996 de GitHub rastreó el problema hasta el punto de entrada. En vibe/cli/entrypoint.py, el agente llama a prepare_auto_worktree_session() o prepare_worktree_session() cuando se activa --worktree. Esa llamada hace que Git cree el worktree y dispare post-checkout. El mecanismo de confianza se inicializa después, en init_harness_files_manager(). El resultado es una ventana en la que se ejecuta código controlado por el repositorio antes de que exista ninguna comprobación de confianza que lo detenga.

El issue, titulado «[Security] Remote Code Execution via worktree creation (git hook execution)», incluía un script de Bash completo y listo para copiar y pegar que construye un repositorio malicioso: inicializa un repositorio, hace un commit inicial e instala un .git/hooks/post-checkout que ejecuta id > /tmp/POC. El informador también indicó la evaluación de gravedad directamente en el issue, enumerando el vector CVSS 3.1 AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H y la puntuación de 8,8. El issue se presentó contra la v2.24.1.

Para ver por qué importaba el orden, conviene separar los dos conceptos de Git en juego. Un worktree es un segundo directorio de trabajo enlazado al mismo repositorio, y crearlo hace checkout de archivos y por tanto dispara hooks relacionados con el checkout. Un hook de Git es un script guardado dentro del repositorio, en .git/hooks/, y post-checkout se ejecuta automáticamente tras un checkout o la creación de un worktree. Un hook es contenido normal del repositorio, así que un atacante que controla el repositorio controla el script. Normalmente no interviene ninguna configuración ni aprobación, porque el usuario ya ha pedido a Git que haga checkout del código.

El ataque sigue requiriendo que un usuario apunte el agente a un repositorio hostil, por ejemplo clonándolo o importándolo y luego ejecutando Vibe allí. El vector CVSS lo refleja: vector de ataque de red con interacción del usuario requerida (UI:R). En la práctica, la entrega es ingeniería social, un paquete con typosquatting o cualquier repositorio al que se pida a un desarrollador que «eche un vistazo rápido». Es un listón bajo para una herramienta diseñada para abrir y razonar sobre código desconocido.

Una prueba de concepto pública estuvo más de cinco semanas expuesta

La cronología de la divulgación es inusual. Según la propia API de GitHub, el issue #996 se creó el 11 de agosto de 2026 a las 22:12 UTC por un usuario llamado therealcoiffeur, se etiquetó como security, bug, CLI y Security and Compliance, y se asignó a un responsable. Llevaba la prueba de concepto a la vista y recibió cero comentarios. Se cerró el 18 de septiembre de 2026 a las 10:57 UTC. Mistral publicó la v2.25.5 a las 11:09 UTC de ese mismo día, unos doce minutos después, desde el commit c069ffa.

El issue estuvo abierto algo más de 37 días. El sitio de noticias y análisis de seguridad agenccy.ai enmarcó la misma brecha como 37 días y sostuvo que el episodio se ha malinterpretado como una divulgación coordinada que funcionó, cuando el informe no fue ni coordinado ni privado. Ese encuadre es análisis y no una declaración del proveedor, pero las marcas de tiempo subyacentes son públicas.

La corrección llegó como una sola línea dentro de una larga lista de «Fixed». Las notas de la v2.25.5 dicen: «Crear o limpiar un worktree ya no ejecuta los hooks de git propios del repositorio (como post-checkout) ni su comando fsmonitor». Un elemento relacionado de la misma versión añadía «guía de divulgación de vulnerabilidades e instrucciones de reporte privado en SECURITY.md», lo que en sí es una señal de que faltaba un canal de reporte privado mientras el informe estuvo público. La corrección de ejecución remota de código no se destaca como una corrección de seguridad, y a 21 de septiembre Mistral no había publicado un aviso independiente que nombrara el CVE, así que un usuario que hojea el registro de cambios no encontraría ninguna razón obvia para actualizar con urgencia.

La ruta de divulgación plantea un dilema conocido. Un informe público y no coordinado con un exploit funcional puede forzar la mano de un proveedor y avisar a los defensores, pero también entrega a los atacantes una herramienta lista y puede dejar expuestos a los usuarios todo el tiempo que se ignore el informe. Aquí la prueba de concepto era inofensiva, escribía la salida de id en un archivo, pero la misma técnica sustituye cualquier comando. El silencio de un responsable ante un problema de seguridad público durante más de cinco semanas es la parte de la historia que interesará a otros proyectos que distribuyen herramientas agénticas.

De dónde salió el 8,8

El CVE lo asignó VulnCheck, no Mistral, y el aviso de VulnCheck acredita a Mathieu Farrell como descubridor. El issue público lo abrió therealcoiffeur; el registro público no dice a las claras si son la misma persona, así que el crédito y el informe deben tratarse como hechos separados.

El registro del CVE, publicado en CVE.org el 19 de septiembre a las 22:58 UTC y en el NVD a las 23:17 UTC, incluye dos puntuaciones. La puntuación base de CVSS 3.1 es 8,8 (alta) con el vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, y una puntuación base de CVSS 4.0 de 8,6 (alta). La debilidad se clasifica como CWE-829, «Inclusion of Functionality from Untrusted Control Sphere». El paquete afectado es pkg:pypi/mistral-vibe, versiones 0 hasta la 2.25.5 sin incluirla. El NVD listaba el registro con estado «Received» a 21 de septiembre, lo que significa que aún no había pasado por el propio enriquecimiento del NVD.

Ambas puntuaciones vienen de VulnCheck y, según el análisis de agenccy.ai, el 8,8 es el vector que el informador escribió en el issue público, trasladado al CVE por la CNA. No aparece ninguna gravedad aportada por el proveedor en el registro. Eso importa para cómo se lee la cifra: es una evaluación de terceros creíble, no la de Mistral, y debe tratarse en consecuencia.

Por qué sigue ocurriendo y cómo responder

Los agentes de programación ejecutan contenido no confiable de repositorios por diseño. Leen archivos, instalan dependencias, ejecutan comandos de compilación y prueba y a menudo tocan Git. Eso convierte la frontera entre «el código que inspeccionamos» y «el código que ejecutamos» en todo el modelo de seguridad, y es fácil equivocarse con el orden. Cualquier paso que haga que Git, un gestor de paquetes o un script de compilación se ejecuten antes de la decisión de confianza es una posible ruta de ejecución previa a la aprobación. Los hooks de Git son un ejemplo clásico, porque se ejecutan automáticamente y están guardados dentro del propio repositorio.

Vibe no es el único agente que se ha topado con esto. Un fallo independiente divulgado en septiembre de 2026, seguido como Plugin4Shell, permitía a un plugin de confianza ejecutar código del atacante en los sistemas de plugins de Claude Code, Codex de OpenAI, GitHub Copilot y la CLI Gemini de Google. El mecanismo allí era una elusión del anclaje por SHA y no un hook de Git, pero la pregunta de fondo es la misma para todo agente que abre código de terceros: qué se ejecuta antes de la decisión de confianza y quién lo controla. Los agentes que gestionan Git por su cuenta heredan la superficie de ejecución de Git, incluidos hooks, filtros, controladores de diff externos y comandos de monitorización de archivos. Las notas de la v2.25.5 muestran que Mistral tuvo que desactivar varias de esas rutas, incluido el hook de checkout, al limpiar el manejo de worktrees.

La respuesta para los usuarios es sencilla. Actualice Vibe a la 2.25.5 o posterior, que impide que la creación y la limpieza de worktrees ejecuten los hooks del repositorio. Trate el aviso de confianza como significativo solo si ocurre antes de la ejecución, y no solo por lo que ocurre después. Sea precavido con repositorios de fuentes que no controla incluso en versiones parcheadas, porque los nuevos fallos de orden de operaciones son un patrón recurrente y no un caso aislado. Donde el flujo de trabajo lo permita, ejecute el agente en un contenedor o una máquina virtual desechable con credenciales limitadas, para que un hook que sí se dispare no pueda alcanzar las claves SSH, los tokens de nube o el árbol de código reales del desarrollador. Los equipos también pueden fijar core.hooksPath a un directorio vacío fuera del repositorio como medida de defensa en profundidad, aunque eso es una mitigación para esta clase de fallo, no un sustituto de actualizar. Para los responsables de mantenimiento, la lección es revisar qué hace un agente de programación al arrancar, antes de cualquier paso de aprobación, y no solo lo que hace dentro de una sesión.

Qué hay que observar ahora: si Mistral publica su propio aviso con una puntuación de gravedad del proveedor, si la pull request de corrección aún abierta #1032, titulada «fix(git): disable repository hooks during worktree creation», se fusiona o queda reemplazada por el commit de la versión, y si otros proveedores de agentes auditan sus propias rutas de hooks y checkout. La línea de crédito y el punto del registro de cambios ya son públicos. La pregunta abierta es con qué rapidez el resto de la categoría comprueba la misma secuencia.

Portada: el cofundador y consejero delegado de Mistral AI, Arthur Mensch, en Techarena 2026, por Jan2342342423 (CC0 1.0) vía Wikimedia Commons, recortada a 16:9.