DeepSeek Harness Sandbox-Bypass ermöglichte Agent-Ausbruch

Ein Sicherheitsfehler in DeepSeek Harness, dem Open-Source-Tool zum Ausführen von KI-Coding-Agenten auf dem Rechner eines Entwicklers, erlaubte einem in einer Sandbox laufenden Agenten, seine eigene Datei-Sandbox mit einem einzigen Befehl abzuschalten. Das Tool führt die Befehle eines Agenten normalerweise innerhalb einer Betriebssystem-Sandbox aus, einer Schutzgrenze, die verhindern soll, dass ein Agent, der an nicht vertrauenswürdigen Dateien arbeitet, außerhalb seines zugewiesenen Arbeitsbereichs schreibt. Bei einer Standardinstallation konnte dieser Agent jedoch die eigene lokale Web-Oberfläche des Tools auf demselben Rechner aufrufen, seine Sitzung auf einen Modus namens danger-full-access umstellen und dann Befehle außerhalb der Sandbox ohne jede Genehmigungsabfrage ausführen. Dies funktionierte, bis DeepSeek das Tool am 27. August behob, und es erforderte vom Angreifer gelieferten Text, den der Agent las, um ihn zu diesem Aufruf zu veranlassen. Die Schwachstelle wird als CVE-2026-82533 geführt. VulnCheck, das die Kennung vergab, veröffentlichte den Eintrag am 8. September und bewertete die Schwachstelle mit 9,4 von 10.

OX Research, die Sicherheitsfirma, die die Schwachstelle meldete, sagte, ein einziger Shell-Befehl habe ausgereicht. Der Befehl rief die lokale Oberfläche des Tools auf und setzte die Sitzung des Agenten auf danger-full-access, wodurch die Sandbox abgeschaltet und Genehmigungsabfragen gestoppt werden. Gewöhnliche Befehle brauchten ohnehin keine Genehmigung. Eine Genehmigung wurde nur verlangt, wenn ein Befehl einen umfassenderen Zugriff anforderte, als die Sitzung bereits hatte, und dieser Aufruf forderte keinen umfassenderen Zugriff an; er änderte stattdessen die Einstellung der Sitzung. OX erklärte, es habe geprüft, dass die Sandbox vor dem Ausbruch funktioniert habe. Es führte zwei Sitzungen mit denselben Standardeinstellungen aus und gab beiden denselben Befehl. Die Sitzung, die den Aufruf getätigt hatte, schrieb in einen Ordner außerhalb ihres Arbeitsbereichs, und die andere Sitzung wurde blockiert.

Die Sandbox deckt nur Dateien ab. Die Kommandozeilen-Referenz für die betroffene Version besagt, dass bei der Standardeinstellung Schreibvorgänge im Arbeitsbereich und in temporären Ordnern bleiben, während „Lesezugriffe und Netzwerkzugriff nicht eingeschränkt sind“. Dadurch blieb die eigene Oberfläche des Tools aus der Sandbox heraus erreichbar. Das Tool stellt der Shell des Agenten außerdem die Adresse dieser Oberfläche und die Kennung der aktuellen Sitzung bereit, sodass der Agent sie nicht suchen muss. Die Oberfläche hatte keine Authentifizierung. In der betroffenen Version las die Prüfung, die entschied, ob eine Anfrage sie erreichen konnte, den Host-Header der Anfrage und sah sich nie an, woher die Verbindung stammte. Ein Kommentar in dieser Datei besagt, die Prüfung „ist keine Authentifizierungsschicht“. Genau diese Prüfung beschreibt der CVE-Eintrag. Weil sie einem vom Client gelieferten Header vertraute, konnte sich ein Rechner von außen als lokal ausgeben und den Agenten steuern. Die Kommandozeile des Tools weigerte sich, auf allen Netzwerkschnittstellen zu lauschen, sodass ein Zugriff von außen erforderte, dass der Nutzer den Port durch einen Tunnel, eine SSH-Weiterleitung oder einen Editor weitergeleitet oder als Proxy bereitgestellt hatte. Dieselbe Oberfläche bediente auch eine Anfrage zum Herunterladen des gesamten Protokolls einer Sitzung. Der Advisory von VulnCheck stellt fest, dass ein Aufrufer, der die Oberfläche erreicht, alle gespeicherten Unterhaltungen ohne Schlüssel abrufen könnte.

Betroffen sind Versionen 0.1.1-rc.2 und früher. Der Eintrag nennt 0.1.2-alpha.1 als behobene Version, aber diese Version wurde nie in der npm-Registry veröffentlicht, dem Online-Paketkatalog, auf den die eigenen Anweisungen des Projekts die Nutzer verweisen. Die erste behobene Veröffentlichung auf npm war 0.1.2-alpha.2, veröffentlicht am 30. August. Die aktuelle npm-Version, 0.1.2-rc.1, enthält die Korrektur und wurde am 3. September veröffentlicht. The Hacker News prüfte die Registry am 9. September und stellte fest, dass die erste veröffentlichte Version mit der Authentifizierungsänderung 0.1.2-alpha.2 ist, drei Tage nachdem die Korrektur auf GitHub eingespielt wurde. Nutzer sollten 0.1.2-alpha.2 oder später installieren. Wenn sie das Harness über eine Desktop-App eines Drittanbieters installiert haben, sollten sie prüfen, welche Version des Harness sie mitliefert. Wenn sie nicht aktualisieren können, sollten sie die Web-Oberfläche stoppen, wenn sie nicht verwendet wird, und jeden Tunnel, Proxy oder jede Portweiterleitung entfernen, die sie erreicht. Keine für diesen Artikel geprüfte Quelle bietet eine Möglichkeit, den Ausbruch aus der Sandbox bei einer standardmäßigen lokalen Installation zu verhindern, solange das Tool läuft. Der Bericht vom 13. August besagt, dass eine Einschränkung der Adresse, auf der das Tool lauscht, nicht hilft, weil der Agent bereits auf demselben Rechner ist.

Die Korrektur gibt der Oberfläche eine Identitätsprüfung. Das Tool gibt nun beim Start eine Einmal-Token an seiner Startadresse aus; der Browser tauscht diese Token gegen ein signiertes Cookie ein, und jeder Aufruf der Oberfläche erfordert das Cookie. Was die Korrektur nicht ändert, ist die Sandbox. In 0.1.2-rc.1 besagt dieselbe Referenz weiterhin, dass Lesezugriffe und Netzwerkzugriff nicht eingeschränkt sind, und die Shell des Agenten erhält weiterhin die Adresse der Oberfläche. Keine Quelle geht darauf ein, ob ein innerhalb seines Arbeitsbereichs laufender Agent unter dem neuen Schema noch eine gültige Sitzung erhalten kann. Desktop-Builds von Drittanbietern liefern ihre eigene Kopie des Harness mit, und welche Kopie sie mitliefern, liegt im Ermessen des Wrapper-Maintainers. Ein Windows-Build fixierte Ende August 0.1.1-rc.2 und wechselte am 6. September zu 0.1.3-alpha.1, die die Korrektur enthält. Wer das Harness über einen Wrapper installiert hat, sollte prüfen, welche Version er mitliefert.

Ein Coding-Agent-Harness ist es wert, angegriffen zu werden, weil es eine Shell besitzt. DeepSeek Harness führt die Befehle eines Agenten unter dem Konto aus, das es gestartet hat. Der eigene Sicherheitshinweis des Projekts stellt fest, dass die Software keinem Sicherheitsaudit unterzogen wurde und dass Sandboxing und Genehmigungsabfragen „keine Isolation garantieren oder Schaden verhindern“. Er weist Nutzer an, sich nicht auf das Tool als einzige Sicherheitskontrolle für nicht vertrauenswürdige Arbeit zu verlassen. Das Repository hatte am 9. September mehr als 216.000 Sterne, eine Zahl von Konten, die es mit Lesezeichen versehen haben, nicht von Installationen. Forscher haben in diesem Jahr wiederholt festgestellt, dass Coding-Agenten aus ihren Sandboxes entkommen, darunter eine Reihe von Schwachstellen, bei denen die eigene Konfiguration eines Repositorys dazu führte, dass Agenten Angreifer-Code außerhalb ihrer Sandboxes ausführten.

Community-Berichte beschrieben denselben Ausbruch im August auf DeepSeeks eigenem Diskussionsforum. Am 13. August veröffentlichte ein Entwickler einen Bericht, der zeigte, wie ein noch von der Sandbox gehaltener Prozess die lokale Oberfläche erreichte und dann die Sitzung auf danger-full-access umstellte, mit Testausgabe. Am 14. August veröffentlichte ein anderer Entwickler einen Bericht, der die Anfragen auflistete, die die Oberfläche ohne jegliche Anmeldedaten akzeptierte. Dieser zweite Bericht merkte auch an, dass das Projekt keine Datei mit Sicherheitsrichtlinie und keinen privaten Weg zur Meldung einer Schwachstelle hatte. Das Projekt hat noch immer keine Datei mit Sicherheitsrichtlinie. OX Research meldete die Schwachstelle nach seiner eigenen Zeitlinie am 24. August an VulnCheck, und VulnCheck nennt Nir Zadok und Moshe Siman Tov Bustan als Urheber. OX' Beitrag erwähnt die früheren Berichte nicht. The Hacker News prüfte die Advisory-Liste des Repositorys am 9. September und fand keinen veröffentlichten Sicherheitshinweis. Die Version, die die Korrektur enthielt, listet sie unter routinemäßigen Änderungen auf, als Entfernung eines alten Transports und Erfordernis von „Einmal-Token-Authentifizierung für Netzwerkzugriff“, ohne Sicherheitshinweis und ohne Erwähnung der CVE.

Für Teams, die Coding-Agenten ausführen oder Anwendungen in Produktion hosten, bietet AEU-I sicherheitsorientierte IT, Infrastruktur und Beratung – ein nützlicher Ausgangspunkt bei der Überprüfung, wie Tools wie DeepSeek Harness bereitgestellt und gehärtet werden. Der unmittelbarste Schutz für einzelne Nutzer besteht darin, auf eine behobene Version zu aktualisieren, Wrapper-Builds zu überprüfen und jeden Pfad zu entfernen, der die lokale Oberfläche exponiert, solange das Tool läuft.