GitLab entdeckt Schwachstelle ConfigPoisoning: Manipulierte Repository-Konfigurationen können KI-Coding-Agenten kapern

Die Threat Research Group von GitLab hat eine Schwachstelle zur Befehlsausführung in DeepSeek-Reasonix Studio offengelegt, einem Desktop-Git-Client für Entwickler, die mit KI-Coding-Assistenten arbeiten. Die ConfigPoisoning genannte Lücke konnte dazu führen, dass vom Angreifer eingeschleuster Code läuft, sobald ein Entwickler den Diff einer Datei ansieht.
- Die Threat Research Group von GitLab hat ConfigPoisoning (CVE-2026-102437) in DeepSeek-Reasonix Studio offengelegt.
- Beim Anzeigen des Diffs einer Datei konnte Angreifercode laufen, und zwar über einen filter.<driver>.clean-Eintrag in .gitattributes und .git/config.
- Behoben in DeepSeek-Reasonix Studio 2.21.0 und DeepSeek Reasonix npm 1.39.3.
- Laut GitLab weisen mehrere weitere weit verbreitete Coding-Agenten dieselbe Klasse von Schwachstellen auf und unterliegen einer koordinierten Offenlegung.
- Auf GitLab gehostete Repositories sind laut GitLab nicht betroffen.
Was GitLab entdeckt hat
Die Schwachstelle wird unter GHSA-grg2-7gc6-36m6 und CVE-2026-102437 geführt. Laut GitLab betrifft sie sowohl die Desktop-App DeepSeek-Reasonix als auch das npm-Paket. Nutzer sollten auf DeepSeek-Reasonix Studio 2.21.0 beziehungsweise DeepSeek Reasonix npm 1.39.3 aktualisieren.
GitLab betont, dass es sich nicht um einen Einzelfall handelt. Die Forscher stellten fest, dass mehrere weit verbreitete Coding-Agenten für dieselbe Klasse von Schwachstellen anfällig sind, bei der vom Angreifer kontrollierte Befehle aus den repositoryeigenen Dateien .git/config und .gitattributes ausgeführt werden. DeepSeek-Reasonix ist der erste Fall, den GitLab vollständig offenlegt.
Außerdem weist GitLab darauf hin, dass auf GitLab gehostete Git-Repositories nicht betroffen sind, da beim Klonen über HTTPS oder SSH keine lokalen Konfigurationsdateien übertragen werden.
So funktioniert der Angriff
Coding-Agenten führen Git in jedem Verzeichnis aus, das ein Entwickler öffnet, und übernehmen dabei .git/config und .gitattributes von demjenigen, der das Repository erstellt hat. Mehrere Git-Konfigurationsschlüssel, darunter core.fsmonitor, core.hooksPath, diff.external und filter.<driver>.clean, führen bei gewöhnlichen Git-Vorgängen einen hinterlegten Befehl aus.
Laut GitLab entschärft der Git-Wrapper von DeepSeek-Reasonix bei jedem Aufruf core.fsmonitor und maintenance.auto und hängt an Diffs die Optionen --no-ext-diff und --no-textconv an. filter.<driver>.clean bleibt dagegen unberührt. Ein Code-Kommentar im Projekt nannte dies als die eine Lücke, die noch nicht geschlossen war. Da .gitattributes diesen Schlüssel dateiweise auswählt, lässt sich die Lücke nicht wie die anderen mit einer festen Sperrliste schließen.
GitLab beschreibt die Angriffskette so:
- Eine Datei wie secret.bin wird in .gitattributes einem Filtertreiber namens pwn zugewiesen, und die .git/config des Repositorys definiert den Clean-Befehl dieses Treibers als Skript des Angreifers.
- Ein Entwickler öffnet den Diff der Datei in der Desktop-App.
- DeepSeek-Reasonix führt seinen gehärteten Diff-Befehl aus, doch Git ruft weiterhin den Clean-Filter auf, um den Vergleichs-Blob zu erzeugen.
- Der Befehl des Angreifers wird für jede Seite des Diffs einmal ausgeführt.
Laut GitLab lässt git status den Filter unangetastet, weil es nur prüft, welche Dateien sich geändert haben. Der Fehler beschränkt sich damit auf die Darstellung von Diffs.
Angriffswege und die Rolle der Agenten
.gitattributes übersteht einen Klon, .git/config dagegen nicht. Für die Auslieferung braucht es laut GitLab daher ein Archiv, einen synchronisierten Ordner, einen CI-Cache oder einen Devcontainer-Build. Das Team bestätigte das Problem beim Commit ea28602 und beim getaggten Pre-Release studio-v2.9.0.
GitLab verweist zudem auf einen direkteren Angriffsweg, der speziell für agentische Werkzeuge gilt. Ein abtrünniger, kompromittierter oder per Prompt Injection manipulierter Coding-Agent, der bereits auf dem Rechner des Entwicklers läuft, besitzt dessen Dateisystemzugriff. Er kann die manipulierte .git/config in ein Repository schreiben, das ganz normal geklont wurde.
Das Grundproblem sei, so GitLab, dass Werkzeuge die Repository-Konfiguration als Teil des Werkzeugs behandeln, obwohl sie der Autor des Repositorys kontrolliert. Anfang des Jahres stieß die Gruppe bei Serena, einem weiteren KI-Coding-Werkzeug, auf ein ähnliches Muster: Es führte Angreifercode aus der Datei .serena/project.yml des Projekts aus, sobald ein Entwickler das Repository öffnete.
Was Nutzer und Tool-Entwickler tun sollten
Nutzer von DeepSeek-Reasonix sollten auf Studio 2.21.0 oder npm 1.39.3 aktualisieren. Bei älteren Versionen rät GitLab, keine Diffs von Repositories anzuzeigen, die nicht per direktem Klon bezogen wurden.
Entwicklern von Werkzeugen, die Git kapseln, empfiehlt GitLab, Blobs mit git cat-file oder git show zu lesen und Diffs im eigenen Prozess zu berechnen, wenn nur der Inhalt auf Byte-Ebene benötigt wird. Muss ein Tool eine Shell aufrufen, sollte es bei jedem Aufruf alle relevanten Schlüssel überschreiben, darunter core.fsmonitor, core.pager, core.editor, core.hooksPath, diff.external, core.sshCommand sowie filter.<driver>.clean oder smudge für jeden Treibernamen. GitLab betont, dass eine Option nicht die andere ersetzt: --no-ext-diff wirkt auf diff.external, bewirkt aber nichts bei core.sshCommand. Zudem rät GitLab, vor der Auslieferung gegen ein bewusst feindliches Konfigurationspaar zu testen.
Sicherheitsteams sollten laut GitLab von Herstellern wissen wollen, wie diese repositorylokale Konfiguration entschärfen, und nicht nur, wie sie mit einem nicht vertrauenswürdigen Remote umgehen.
Zeitplan der Offenlegung und Ausblick
GitLab eröffnete das Advisory beim Maintainer esengine am 2026-08-27. Am 2026-09-29 legte esengine einen temporären privaten Fork an und akzeptierte den Bericht. Am 2026-09-30 wurde der Fix ausgeliefert, das Advisory veröffentlicht und die CVE vergeben.
Laut GitLab findet sich dasselbe Muster in mehreren anderen weit verbreiteten Agenten-Werkzeugen, die derzeit einer koordinierten Offenlegung unterliegen. Details zu jedem Fall will GitLab veröffentlichen, sobald ein Fix verfügbar ist.

