Mistral Vibe führte die Git-Hooks eines Repositorys vor der Vertrauensprüfung aus und ermöglichte RCE

Mistral hat eine Remote-Code-Execution-Lücke in seinem Coding-Agenten Vibe behoben, mit der ein bösartiges Repository Shell-Befehle auf dem Rechner eines Entwicklers ausführen konnte, und zwar über genau den Pfad, der dieses Repository in Schach halten sollte. Der Fehler läuft als CVE-2026-93993. Er betrifft Mistral Vibe vor Version 2.25.5 und wird mit 8,8 von 10 (High) auf der CVSS-3.1-Skala bewertet. Mistral veröffentlichte v2.25.5 am 18. September 2026, rund zwölf Minuten, nachdem das öffentliche GitHub-Issue mit der Beschreibung des Fehlers geschlossen worden war.

Zum Weiterlesen: Eine Zero-Click-Lücke ließ bösartige Plugins Code in vier großen KI-Coding-Agenten ausführen · Von KI entdeckter Authentifizierungs-Bypass in Rejetto HFS zieht Ausnutzungsversuche nach sich.

Der verwundbare Code führte bei der Erstellung eines Worktrees die Git-Hooks eines Repositorys aus, bevor der Agent entschieden hatte, ob diesem Repository zu trauen ist. Git führt beim Anlegen eines Worktrees automatisch einen post-checkout-Hook aus, sodass ein Repository einen Hook mitbringen konnte, der Befehle des Angreifers mit den Rechten des Nutzers ausführte, der Vibe gestartet hatte. Der Nutzer stimmte nichts zu, weil die Zustimmungsabfrage, die diese Werkzeuge als ihre Sicherheitsgrenze präsentieren, erst erschien, nachdem die Nutzlast bereits gelaufen war.

Die Reihenfolge der Schritte war die Schwachstelle

Vibe ist Mistrals quelloffener, terminalnaher Coding-Agent, verbreitet als PyPI-Paket mistral-vibe. Er unterstützt das Flag --worktree, das einen separaten verknüpften Arbeitsbaum anlegt, damit die Änderungen des Agenten den Haupt-Checkout des Nutzers nicht berühren. Dieses Flag ist die Option, die ein vorsichtiger Nutzer gerade deshalb wählt, um ein nicht vertrauenswürdiges Repository auf Abstand zu halten.

Der Melder, der GitHub-Issue #996 einreichte, verfolgte das Problem bis zum Einstiegspunkt. In vibe/cli/entrypoint.py ruft der Agent prepare_auto_worktree_session() oder prepare_worktree_session() auf, wenn --worktree gesetzt ist. Dieser Aufruf veranlasst Git, den Worktree anzulegen und post-checkout auszulösen. Die Vertrauensmechanik wird erst später initialisiert, in init_harness_files_manager(). Das Ergebnis ist ein Fenster, in dem vom Repository kontrollierter Code läuft, bevor es eine Vertrauensprüfung gibt, die ihn aufhalten könnte.

Das Issue mit dem Titel „[Security] Remote Code Execution über die Erstellung eines Worktrees (Ausführung eines Git-Hooks)“ enthielt ein vollständiges, kopierbares Bash-Skript, das ein bösartiges Repository aufbaut: Es initialisiert ein Repo, macht einen ersten Commit und installiert einen .git/hooks/post-checkout, der id > /tmp/POC ausführt. Der Melder nannte die Schwereinschätzung auch direkt im Issue, mit dem CVSS-3.1-Vektor AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H und der Bewertung 8,8. Das Issue wurde gegen v2.24.1 eingereicht.

Um zu sehen, warum die Reihenfolge zählte, hilft es, die beiden Git-Konzepte zu trennen, die hier im Spiel sind. Ein Worktree ist ein zweites Arbeitsverzeichnis, das mit demselben Repository verknüpft ist; seine Erstellung checkt Dateien aus und löst damit checkout-bezogene Hooks aus. Ein Git-Hook ist ein Skript, das im Repository unter .git/hooks/ liegt, und post-checkout läuft automatisch nach einem Checkout oder der Erstellung eines Worktrees. Ein Hook ist gewöhnlicher Repository-Inhalt, ein Angreifer, der das Repository kontrolliert, kontrolliert also das Skript. Normalerweise ist keine Konfiguration und keine Zustimmung nötig, weil der Nutzer Git bereits gebeten hat, den Code auszuchecken.

Der Angriff verlangt weiterhin, dass ein Nutzer den Agenten auf ein feindliches Repository richtet, etwa indem er es klont oder importiert und Vibe dort startet. Der CVSS-Vektor spiegelt das: Netzwerk-Angriffsvektor mit erforderlicher Nutzerinteraktion (UI:R). In der Praxis erfolgt die Zustellung über Social Engineering, ein Typosquatting-Paket oder irgendein Repository, von dem ein Entwickler gebeten wird, „schnell einmal hineinzuschauen“. Das ist eine niedrige Hürde für ein Werkzeug, das dafür gedacht ist, unbekannten Code zu öffnen und zu durchdenken.

Ein öffentlicher Proof of Concept lag über fünf Wochen herum

Die Offenlegungs-Chronologie ist ungewöhnlich. Laut GitHub-API wurde Issue #996 am 11. August 2026 um 22:12 UTC von einem Nutzer namens therealcoiffeur angelegt, mit den Labels security, bug, CLI und Security and Compliance versehen und einem Maintainer zugewiesen. Es enthielt den Proof of Concept offen und erhielt null Kommentare. Es wurde am 18. September 2026 um 10:57 UTC geschlossen. Mistral veröffentlichte v2.25.5 am selben Tag um 11:09 UTC, etwa zwölf Minuten später, aus Commit c069ffa.

Das Issue war etwas mehr als 37 Tage offen. Die Seite für Sicherheitsnachrichten und -analysen agenccy.ai rahmte dieselbe Lücke mit 37 Tagen und argumentierte, die Episode werde als koordinierte Offenlegung missverstanden, die funktioniert habe, obwohl der Bericht weder koordiniert noch vertraulich war. Diese Rahmung ist Analyse und keine Aussage des Anbieters, doch die zugrunde liegenden Zeitstempel sind öffentlich.

Der Fix kam als einzelne Zeile in einer langen Liste „Fixed“ an. Die Hinweise zu v2.25.5 lauten: „Das Erstellen oder Bereinigen eines Worktrees führt nicht mehr die eigenen Git-Hooks des Repositorys aus (etwa post-checkout) oder dessen fsmonitor-Befehl.“ Ein verwandter Eintrag derselben Version ergänzte „Anleitung zur Offenlegung von Schwachstellen und Hinweise zur vertraulichen Meldung in SECURITY.md“, was selbst ein Signal dafür ist, dass ein vertraulicher Meldeweg fehlte, während der Bericht öffentlich lag. Der Fix für die Remote-Code-Execution wird nicht als Sicherheitsfix hervorgehoben, und bis zum 21. September hatte Mistral keine eigenständige Empfehlung veröffentlicht, die die CVE nennt, sodass ein Nutzer, der das Changelog überfliegt, keinen offensichtlichen Grund findet, dringend zu aktualisieren.

Der Offenlegungsweg bringt einen bekannten Zielkonflikt mit sich. Ein öffentlicher, unkoordinierter Bericht mit funktionierendem Exploit kann einen Anbieter zum Handeln zwingen und Verteidiger warnen, doch er liefert Angreifern auch ein fertiges Werkzeug und kann Nutzer so lange bloßstellen, wie der Bericht ignoriert wird. Hier war der Proof of Concept harmlos und schrieb die Ausgabe von id in eine Datei, doch dieselbe Technik ersetzt jeden beliebigen Befehl. Das Schweigen eines Maintainers zu einem öffentlichen Sicherheitsproblem über mehr als fünf Wochen ist der Teil der Geschichte, der andere Projekte mit agentischen Werkzeugen interessieren wird.

Woher die 8,8 kommen

Die CVE wurde von VulnCheck vergeben, nicht von Mistral, und VulnChecks Empfehlung nennt Mathieu Farrell als Finder. Das öffentliche Issue wurde von therealcoiffeur eröffnet; der öffentliche Datensatz sagt nicht direkt, ob die beiden dieselbe Person sind, daher sollten die Nennung und der Bericht als getrennte Fakten behandelt werden.

Der CVE-Eintrag, am 19. September um 22:58 UTC auf CVE.org und um 23:17 UTC beim NVD veröffentlicht, trägt zwei Bewertungen. Die CVSS-3.1-Basisscore liegt bei 8,8 (High) mit dem Vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, dazu eine CVSS-4.0-Basisscore von 8,6 (High). Die Schwäche ist als CWE-829 klassifiziert, „Inclusion of Functionality from Untrusted Control Sphere“. Das betroffene Paket ist pkg:pypi/mistral-vibe, Versionen 0 bis ausschließlich 2.25.5. Das NVD führte den Eintrag mit dem Status „Received“ (Stand 21. September), was bedeutet, dass er die eigene Anreicherung des NVD noch nicht durchlaufen hatte.

Beide Bewertungen stammen von VulnCheck, und laut der Analyse von agenccy.ai ist die 8,8 der Vektor, den der Melder im öffentlichen Issue schrieb und den die CNA in die CVE übernahm. Im Eintrag erscheint keine vom Anbieter gelieferte Schwere. Das ist wichtig dafür, wie die Zahl gelesen wird: Es ist eine glaubwürdige Einschätzung Dritter, nicht Mistrals eigene, und sie sollte entsprechend behandelt werden.

Warum das immer wieder passiert und wie man reagiert

Coding-Agenten führen von nicht vertrauenswürdigen Repositorys stammenden Code konstruktionsbedingt aus. Sie lesen Dateien, installieren Abhängigkeiten, führen Build- und Testbefehle aus und berühren oft Git. Damit ist die Grenze zwischen „Code, den wir prüfen“ und „Code, den wir ausführen“ das ganze Sicherheitsmodell, und es ist leicht, die Reihenfolge falsch hinzubekommen. Jeder Schritt, der Git, einen Paketmanager oder ein Build-Skript vor der Vertrauensentscheidung zur Ausführung bringt, ist ein potenzieller Pfad zur Ausführung vor der Zustimmung. Git-Hooks sind ein klassisches Beispiel, weil sie automatisch laufen und im Repository selbst gespeichert sind.

Vibe ist nicht der einzige Agent, der damit in Berührung kam. Eine weitere im September 2026 offengelegte Lücke, geführt als Plugin4Shell, ließ ein vertrauenswürdiges Plugin Angreifercode über die Plugin-Systeme von Claude Code, OpenAIs Codex, GitHub Copilot und Googles Gemini CLI ausführen. Der Mechanismus dort war eine Umgehung der SHA-Pinning-Prüfung statt ein Git-Hook, doch die zugrunde liegende Frage ist für jeden Agenten dieselbe, der fremden Code öffnet: Was läuft vor der Vertrauensentscheidung, und wer kontrolliert es? Agenten, die Git selbst verwalten, erben Git's Ausführungsfläche, einschließlich Hooks, Filter, externer Diff-Treiber und Dateimonitor-Befehle. Die Hinweise zu v2.25.5 zeigen, dass Mistral mehrere dieser Pfade deaktivieren musste, darunter den Checkout-Hook, als es die Worktree-Behandlung bereinigte.

Die Reaktion für Nutzer ist einfach. Vibe auf 2.25.5 oder höher aktualisieren, wodurch Worktree-Erstellung und -Bereinigung keine Repository-Hooks mehr ausführen. Die Vertrauensabfrage nur dann als sinnvoll behandeln, wenn sie vor der Ausführung geschieht, statt nur danach. Bei Repositorys aus Quellen, die man nicht kontrolliert, auch auf gepatchten Versionen vorsichtig sein, weil neue Fehler in der Reihenfolge der Schritte ein wiederkehrendes Muster sind und kein Einzelfall. Wo der Arbeitsablauf es erlaubt, den Agenten in einem Container oder einer Wegwerf-Maschine mit begrenzten Zugangsdaten betreiben, damit ein Hook, der doch auslöst, nicht an die echten SSH-Schlüssel, Cloud-Token oder den Quellbaum des Entwicklers gelangt. Teams können zudem core.hooksPath auf ein leeres Verzeichnis außerhalb des Repositorys setzen, als zusätzliche Absicherung, obwohl das eine Milderung für die Fehlerklasse ist und keinen Ersatz für das Aktualisieren darstellt. Für Maintainer lautet die Lehre, zu prüfen, was ein Coding-Agent beim Start tut, vor jedem Zustimmungsschritt, statt nur, was er innerhalb einer Sitzung tut.

Was nun zu beobachten ist: ob Mistral eine eigene Empfehlung mit Anbieter-Schweregrad veröffentlicht, ob der weiterhin offene Fix-Pull-Request #1032 mit dem Titel „fix(git): Repository-Hooks bei der Worktree-Erstellung deaktivieren“ zusammengeführt oder vom Release-Commit abgelöst wird und ob andere Agenten-Anbieter ihre eigenen Hook- und Checkout-Pfade prüfen. Die Nennungszeile und der Changelog-Punkt sind bereits öffentlich. Die offene Frage ist, wie schnell der Rest der Kategorie dieselbe Abfolge prüft.

Titelbild: Mistral-AI-Mitgründer und CEO Arthur Mensch auf der Techarena 2026, von Jan2342342423 (CC0 1.0) via Wikimedia Commons, auf 16:9 zugeschnitten.