Laut OX Research genügte ein einzelner Shell-Befehl: Er rief die lokale Oberfläche des Werkzeugs auf und setzte die Sitzung des Agenten in den Modus “danger-full-access”, der die Sandbox abschaltet und Bestätigungsabfragen unterdrückt. Gewöhnliche Befehle benötigten ohnehin keine Zustimmung – eine Abfrage erschien nur, wenn ein Kommando mehr Rechte verlangte, als die Sitzung besaß. Genau das tat dieser Aufruf nicht; er veränderte stattdessen die Einstellung der Sitzung.
OX prüfte nach eigener Darstellung, dass die Sandbox vor dem Ausbruch funktionierte: Zwei Sitzungen wurden mit identischen Standardeinstellungen gestartet und erhielten denselben Befehl. Die Sitzung, die den Aufruf abgesetzt hatte, schrieb erfolgreich in einen Ordner außerhalb ihres Arbeitsverzeichnisses, die andere wurde blockiert.
Die Sandbox deckt ausschließlich Dateien ab. In der Kommandozeilen-Referenz der betroffenen Version heißt es, unter der Standardeinstellung blieben Schreibzugriffe auf Arbeitsverzeichnis und temporäre Ordner beschränkt, während “Lesezugriffe und Netzwerkzugriff nicht eingeschränkt” seien. Damit war die eigene Oberfläche des Werkzeugs aus der Sandbox heraus erreichbar – und das Werkzeug übergibt der Shell des Agenten zudem die Adresse dieser Oberfläche sowie die Kennung der laufenden Sitzung.
Eine Authentifizierung gab es nicht. In der betroffenen Version entschied eine Prüfung anhand des vom Client gesetzten Host-Headers, ob eine Anfrage die Oberfläche erreichen durfte; die Herkunft der Verbindung wurde nie betrachtet. Ein Kommentar in der betreffenden Datei stellt fest, die Prüfung “ist keine Authentifizierungsschicht”. Genau diese Prüfung beschreibt der CVE-Eintrag: Weil ein vom Client gelieferter Header vertraut wurde, konnte auch eine externe Maschine behaupten, lokal zu sein, und den Agenten steuern. Da die Kommandozeile das Lauschen auf allen Netzwerkschnittstellen verweigerte, war dafür allerdings eine vom Nutzer eingerichtete Portweiterleitung über Tunnel, SSH oder einen Editor nötig.
Dieselbe Oberfläche lieferte auch das komplette Protokoll einer Sitzung aus. Nach VulnChecks Advisory konnte ein Aufrufer, der die Oberfläche erreicht, sämtliche gespeicherten Konversationen ohne Schlüssel abrufen.
Betroffen sind Versionen 0.1.1-rc.2 und älter. Der Eintrag nennt 0.1.2-alpha.1 als korrigierte Fassung, doch diese Version wurde nie in der npm-Registry veröffentlicht, auf die die Projektanleitung verweist. The Hacker News prüfte die Registry am 9. September: Die erste veröffentlichte Version mit der Authentifizierungsänderung ist 0.1.2-alpha.2, drei Tage nach dem Fix auf GitHub. Der Fix führt eine Identitätsprüfung ein – das Werkzeug zeigt beim Start ein Einmal-Token an, der Browser tauscht es gegen ein signiertes Cookie, das jeder Aufruf benötigt.
An der Sandbox ändert sich nichts: In 0.1.2-rc.1 heißt es weiterhin, Lesezugriffe und Netzwerkzugriff seien nicht eingeschränkt, und die Shell des Agenten erhält weiterhin die Adresse der Oberfläche. Der Bericht vom 13. August hält fest, dass eine Beschränkung der Lauschadresse nicht hilft, weil der Agent bereits auf derselben Maschine läuft.
Zwei Entwickler hatten denselben Ausbruch bereits vor Existenz des CVE im Diskussionsforum von DeepSeek beschrieben – am 13. August mit Testausgabe zum Wechsel in “danger-full-access”, am 14. August mit einer Liste der ohne Anmeldedaten akzeptierten Anfragen. Der zweite Bericht wies darauf hin, dass das Projekt keine Sicherheitsrichtlinie und keinen privaten Meldeweg hat; das gilt weiterhin. OX meldete die Lücke am 24. August an VulnCheck und erwähnt die früheren Berichte nicht.
Drittanbieter-Desktop-Builds liefern eigene Kopien des Harness aus; ein Windows-Build war noch auf 0.1.1-rc.2 festgelegt und wechselte am 6. September auf das korrigierte 0.1.3-alpha.1. Der Sicherheitshinweis des Projekts selbst hält fest, die Software sei nicht sicherheitsgeprüft und Sandbox wie Bestätigungsabfragen “garantieren keine Isolation und verhindern keinen Schaden”. Das Repository hatte am 9. September mehr als 216.000 Sterne; eine Sicherheitsmeldung war dort nicht veröffentlicht – die Fix-Version listet die Änderung nur unter Routinepunkten als “Einmal-Token-Authentifizierung für Netzwerkzugriff”, ohne CVE-Hinweis.
