Kritische Codeausführung in DeepSeek-Reasonix mittels präparierter Git-Konfiguration

Die Threat Research Group von GitLab hat eine Schwachstelle zur Ausführung von Befehlen (GHSA-grg2-7gc6-36m6, CVE-2026-102437) in DeepSeek-Reasonix Studio entdeckt, einem Desktop-Git-Client für die Arbeit mit KI-Coding-Assistenten. Über die Lücke namens ConfigPoisoning kann Code eines Angreifers ausgeführt werden, sobald ein(e) Entwickler(in) den Diff einer Datei anzeigt. Abhilfe schafft das Update auf DeepSeek-Reasonix Studio 2.21.0 oder das npm-Paket DeepSeek Reasonix 1.39.3.

Der Fehler betrifft nicht nur DeepSeek-Reasonix. Die Threat Research Group hat festgestellt, dass mehrere verbreitete Coding-Agenten für dieselbe Klasse von Schwachstellen anfällig sind. In allen Fällen lassen sich Befehle von Angreifern über die Dateien .git/config und .gitattributes des Repositorys selbst ausführen. DeepSeek-Reasonix ist der erste Fall, den wir vollständig offenlegen.

Hinweis: Auf GitLab gehostete Git-Repositorys sind nicht betroffen, da ein Clone über HTTPS oder SSH keine lokalen Konfigurationsdateien überträgt.

Kurz zusammengefasst

• Kritische Schwachstelle: Die Threat Research Group von GitLab hat in DeepSeek-Reasonix Studio, einem Desktop-Git-Client für KI-gestützte Entwicklung, eine kritische Schwachstelle gefunden. Unter bestimmten Konfigurationen des Repositorys kann sie Code von Angreifern ausführen, sobald ein(e) Entwickler(in) den Diff einer Datei anzeigt.
• Die Ursache: Der Git-Wrapper von DeepSeek-Reasonix sichert mehrere Git-Konfigurationsschlüssel gegen Command Injection ab. Ein Kommentar im eigenen Code benennt jedoch eine Lücke, die nie geschlossen wurde: filter.<driver>.clean. Diesen Schlüssel wählt Git pro Datei über .gitattributes aus, nicht über einen festen Konfigurationsschlüssel.
• Sofortmaßnahmen: Auf DeepSeek-Reasonix Studio 2.21.0 oder das npm-Paket DeepSeek Reasonix 1.39.3 aktualisieren. Wer Werkzeuge baut, die Git als externen Prozess aufrufen, sollte nicht nur den einen anfälligen Schlüssel absichern. Entweder alle relevanten Schlüssel bei jedem Aufruf überschreiben oder die Filter- und Textconv-Mechanik von Git ganz umgehen. Über diese Mechanik verändert Git Dateiinhalte, bevor sie committet oder verglichen werden.

Coding-Agenten – eine Angriffsfläche der anderen Art

Coding-Agenten führen Git in jedem Verzeichnis aus, das ein(e) Entwickler(in) öffnet. Dabei übernehmen sie .git/config und .gitattributes von der Person, die das Repository erstellt hat, nicht von der Person, die es öffnet. Mehrere Git-Konfigurationsschlüssel, darunter core.fsmonitor, core.hooksPath, diff.external und filter.<driver>.clean, führen im Rahmen gewöhnlicher Git-Operationen einen benannten Befehl aus. Für klassische Git-Clients gibt es dazu bereits Sicherheitshinweise.

Da jeder Coding-Agent Git auf eigene Weise einbindet, schließt jeder meist nur den Mechanismus, der seinen letzten Vorfall verursacht hat. Das Modul internal/gitcmd von DeepSeek-Reasonix schloss vier dieser Mechanismen bei jedem Aufruf. Den fünften, offenen benannte der eigene Code-Kommentar.

Wie die Schwachstelle funktioniert

internal/gitcmd neutralisiert bei jedem Aufruf core.fsmonitor und maintenance.auto und ergänzt Diffs um --no-ext-diff und --no-textconv. filter.<driver>.clean bleibt dagegen unberührt. Dieser Schlüssel stammt nicht aus einer festen Liste. .gitattributes wählt ihn pro Datei aus, deshalb lässt er sich nicht wie die anderen über eine Denylist schließen.

Hier der tatsächliche Aufruf aus desktop/workspace_changes.go:

      args := []string{"-C", base, "diff", "--no-ext-diff", "--no-textconv", "--relative", "HEAD", "--", filepath.FromSlash(rel)}

    

Der Clean-Filter läuft hier trotzdem. Er erzeugt den Vergleichs-Blob, den der Diff braucht, und dieser Schritt wird von keinem der Flags oben erfasst.

Die vollständige Aufrufkette

Die Kette im Einzelnen:

1. Die Vorbereitung: Ein Eintrag in .gitattributes weist der Datei secret.bin einen Filter-Treiber namens pwn zu, und die Datei .git/config des Repositorys definiert als Clean-Befehl dieses Treibers ein Skript nach Wahl des Angreifers.
2. Die Diff-Ansicht wird geöffnet: Ein(e) Entwickler(in) öffnet in der Desktop-App von DeepSeek-Reasonix den Diff der Datei, ein gewöhnlicher Vorgang bei jeder Datei mit nicht committeter Änderung.
3. DeepSeek-Reasonix führt den abgesicherten Befehl aus: desktop/workspace_changes.go setzt git -c core.fsmonitor=false -c maintenance.auto=false -C <repo> diff --no-ext-diff --no-textconv -- secret.bin ab, mit allen vorhandenen Absicherungs-Flags.
4. Der Clean-Filter läuft trotzdem: Git ruft filter.pwn.clean auf, um den Vergleichs-Blob zu erzeugen, und diesen Schritt berührt keines der Flags. Der Befehl des Angreifers wird ausgeführt, einmal für jede Seite des Diffs.

Beim Nachstellen des abgesicherten Befehls lief die Payload zweimal: Der Diff erzeugt für jede Seite des Vergleichs einen clean-gefilterten Blob, und der Filter greift entsprechend einmal pro Seite. git status prüft dagegen nur, welche Dateien sich geändert haben, erzeugt diesen Blob also nicht und lässt den Filter unberührt. Damit ist der Fehler auf die Darstellung des Diffs eingegrenzt, und das entspricht dem tatsächlichen Codepfad von DeepSeek-Reasonix.

Verbreitung

.gitattributes übersteht einen Clone, .git/config nicht. Für die Zustellung braucht es daher ein Archiv, einen synchronisierten Ordner, einen CI-Cache oder einen Devcontainer-Build. Bestätigt haben wir die Lücke bei Commit ea28602 und beim getaggten Pre-Release studio-v2.9.0. Betroffen sind sowohl die Desktop-App als auch das npm-Paket.

Es gibt allerdings einen direkteren Weg, der speziell für agentische Werkzeuge gilt. Ein bösartiger, kompromittierter oder per Prompt Injection manipulierter Coding-Agent, der bereits auf dem Rechner läuft, hat dieselben Dateisystemrechte wie der oder die Entwickler(in). Er kann die präparierte .git/config direkt in ein ganz normal geklontes Repository schreiben. Ein Archiv, ein synchronisierter Ordner oder ein CI-Cache ist dann nicht nötig.

Warum neue Werkzeuge alte Fehler erben

Das Problem betrifft nicht nur DeepSeek-Reasonix.

• Die Konfiguration des Repositorys wird als Teil des Werkzeugs behandelt: Coding-Agenten lesen .git/config oder .gitattributes, als wären es ihre eigenen Einstellungen. Tatsächlich kontrolliert sie die Person, die das Repository erstellt hat. Dieser Unterschied geht leicht unter, weil die Dateien direkt neben dem Code liegen und so wirken, als gehörten sie dazu.
• Dieses Vertrauensproblem ist schon in einer anderen Datei aufgetreten: Anfang des Jahres hat die Threat Research Group dasselbe Muster in Serena gefunden, einem weiteren KI-Coding-Werkzeug. Serena führte Code eines Angreifers aus der Projektkonfigurationsdatei .serena/project.yml aus, sobald ein(e) Entwickler(in) das Repository öffnete. In beiden Fällen vertraute das Werkzeug einer Datei, die der oder die Autor(in) des Repositorys kontrolliert. Wir gehen davon aus, denselben Fehler auch in weiteren agentischen Werkzeugen zu finden.

Was daraus folgt

Wer DeepSeek-Reasonix einsetzt

Auf Studio 2.21.0 oder das npm-Paket DeepSeek Reasonix 1.39.3 aktualisieren. In älteren Versionen keine Diffs von Repositorys anzeigen, die nicht selbst per direktem Clone bezogen wurden.

Wer Werkzeuge mit Git-Aufrufen baut

Diese Empfehlungen gelten für jedes Werkzeug, das Git als externen Prozess in einem Verzeichnis aufruft, das es nicht selbst kontrolliert.

• Wenn nur der reine Inhalt gebraucht wird, Blobs mit git cat-file oder git show lesen und Diffs im eigenen Prozess berechnen.
• Wenn Git als externer Prozess unvermeidbar ist, alle relevanten Schlüssel bei jedem Aufruf überschreiben. Dazu gehören core.fsmonitor, core.pager, core.editor, core.hooksPath, diff.external, core.sshCommand sowie filter.<driver>.clean oder smudge für jeden Treibernamen in .gitattributes, .git/info/attributes und in globalen oder systemweiten Dateien.
• Ein Flag deckt kein anderes ab. --no-ext-diff wirkt auf diff.external, für core.sshCommand jedoch nicht.
• Nicht davon ausgehen, dass die präparierte Konfiguration mit dem Repository ankommen muss. Ein anderer Agent, eine Erweiterung oder ein Prozess mit den Rechten der Entwickler(innen) kann sie direkt in ein bereits geklontes Repository schreiben.
• Vor der Auslieferung gegen ein bewusst bösartiges Konfigurationspaar testen.

Wer ein Security-Team leitet

Ein Werkzeug, das Git auf dem Rechner von Entwickler(inne)n als externen Prozess aufruft, läuft mit deren vollen Zugriffsrechten. Bei Anbietern deshalb nachfragen, wie sie die lokale Konfiguration von Repositorys neutralisieren, nicht nur, wie sie mit einem nicht vertrauenswürdigen Remote umgehen.

Zeitleiste der Offenlegung

Wir danken den Maintainern von DeepSeek-Reasonix dafür, dass sie die Meldung angenommen und einen Fix ausgeliefert haben.

Wie GitLab unterstützen kann

Der Security Analyst Agent von GitLab Duo Agent Platform hilft dabei, die eigene Codebasis auf dasselbe Muster zu prüfen. Für den Einstieg eignet sich diese Frage an den Agenten:

      "Ruft dieser Code Git als externen Prozess in einem Verzeichnis auf, das er nicht kontrolliert, und neutralisiert er vorher core.hooksPath, filter.*.clean und diff.external?"

    

Der Agent bewertet anschließend die möglichen Auswirkungen auf die eigene Umgebung.

Ausblick

Die Geschichte von DeepSeek-Reasonix zeigt, dass selbst eine gut dokumentierte und offen benannte Sicherheitslücke ausgeliefert werden kann, denn ein Risiko zu kennen und es zu beseitigen ist nicht immer dasselbe. Dasselbe Muster findet sich in mehreren weiteren verbreiteten Agenten-Werkzeugen, für die derzeit eine koordinierte Offenlegung läuft. Details zu jedem Fall veröffentlichen wir, sobald ein Fix verfügbar ist.

Weitere Sicherheitsforschung der GitLab Threat Research Group