DeepSeek Harness CVE-2026-82533: Ein Agent in der Sandbox deaktiviert seine eigene Sandbox mit einem einzigen Befehl

VulnCheck veröffentlichte am 8. September 2026 CVE-2026-82533: eine kritische Authentifizierungsumgehung, die es einem KI-Coding-Agenten ermöglichte, seine eigene Sandbox mit einem einzigen Shell-Befehl abzuschalten. Die Software ist DeepSeek Harness, DeepSeeks quelloffene lokale Laufzeitumgebung für Coding-Agenten, die laut Cloud Security Alliance innerhalb weniger Wochen rund 215.000 GitHub-Sterne erhielt; alle Versionen vor 0.1.2-alpha.1 sind betroffen. Ob ein Aufrufer lokal war, wurde anhand des Host-Headers des Aufrufers selbst beurteilt, sodass eine Anfrage vorgeben konnte, über Loopback zu kommen. Da seine Sandbox Dateischreibvorgänge, aber nicht Loopback-Netzwerkverkehr einschränkte, konnte ein eingeschränkter Agent die nicht authentifizierte Steuerungs-API des Harness auf Port 3080 aufrufen und seine Sitzung auf danger-full-access umstellen, wobei Genehmigungen deaktiviert waren. VulnCheck bewertet sie mit 9,4 (kritisch); eine Ausnutzung in freier Wildbahn wird nicht behauptet. Der Eintrag ist ein Bestandteil eines öffentlichen Datensatzes zu KI-Vorfällen, und das Orca AI Incident Archive enthält den vollständigen Eintragsbestand mit Datumsangaben, Schweregraden und Quellen für jeden Eintrag.

Die Prüfung, die eine Anfrage fragte, was sie war

Die anfällige Komponente ist die lokale Agent-Control-API des Harness, der kleine HTTP-Dienst, den die Weboberfläche und die Kommandozeile nutzen, um eine laufende Sitzung zu steuern. Laut der Forschungsnotiz der Cloud Security Alliance vom 10. September 2026, die sich auf den Bericht von OX Security stützt, der Firma, die die Schwachstelle entdeckt hat, lauschte dieser Dienst standardmäßig auf 127.0.0.1 Port 3080 und traf seine Vertrauensentscheidung in einer Funktion, die die Notiz isTrustedApiRequest nennt. Die Funktion las den HTTP-Host-Header und gewährte Zugriff, wenn der Wert einem Loopback-Namen wie localhost oder 127.0.0.1 entsprach. Ein Host-Header sind Metadaten, die der Client schreibt; er sagt nichts darüber aus, woher die TCP-Verbindung kam. The Hacker News berichtet am 9. September 2026 unter Berufung auf den betroffenen Quellcode, dass die Prüfung nie den Ursprung der Verbindung betrachtete und dass ein Kommentar in derselben Datei besagt, die Prüfung „ist keine Authentifizierungsschicht“.

Das ist der gesamte Inhalt von CWE-807 – das Vertrauen auf nicht vertrauenswürdige Eingaben bei einer Sicherheitsentscheidung – und genau das beschreibt der veröffentlichte Eintrag von VulnCheck: ein vom Client bereitgestellter Loopback-Host-Header, der anstelle der Validierung des tatsächlichen Ursprungs der TCP-Verbindung akzeptiert wird.

Was aus einer fehlerhaften Prüfung einen Fluchtweg machte, war, dass das Harness dem Agenten seine eigenen Schlüssel in die Hand gab. The Hacker News berichtet, dass das Harness der Shell des Agenten die Adresse der Steuerungsschnittstelle und die Kennung der aktuellen Sitzung übergibt, sodass ein Befehl beides nicht erst ermitteln muss. Die Sandbox deckte unterdessen den einen Kanal ab, den anderen nicht: Die Befehlszeilenreferenz 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.

Warum Genehmigungsaufforderungen es nicht gestoppt haben

Das Harness hatte durchaus Genehmigungsabfragen, und sie wurden nicht so sehr umgangen, als vielmehr gar nicht angewandt. Laut The Hacker News wurde in der betroffenen Version eine Genehmigung nur angefordert, wenn ein Befehl auf breiteren Zugriff abzielte, als die Sitzung bereits besaß. Der Eskalationsaufruf verfolgte nichts dergleichen; er änderte die Einstellung der Sitzung. Ein Agent, der ihn ausführte, wechselte in einen Modus, den OX Security danger-full-access nennt, wobei Genehmigungsabfragen auf nie gesetzt waren, und lief weiter als der Benutzer, der das Harness gestartet hatte, vollständig außerhalb der Sandbox.

Der Beweis von OX Security für die Grenze war ein kontrolliertes Paar. The Hacker News berichtet, dass das Unternehmen zwei Sitzungen mit identischen Standardeinstellungen ausführte und beiden denselben Befehl gab: Die Sitzung, die den Aufruf tätigte, schrieb in einen Ordner außerhalb ihres Arbeitsbereichs, und die andere wurde blockiert.

Der zweite Weg – und die Voraussetzung, die er brauchte

Dieselbe fehlende Prüfung setzte die Harness Aufrufern aus, die sich überhaupt nie in einer Sandbox befanden, jedoch nur unter einer Bedingung, die die Standardkonfiguration nicht herstellte. Die Kommandozeile weigerte sich, die API an alle Netzwerkschnittstellen zu binden, sodass der Port von anderswo aus nur erreichbar war, wenn ein Nutzer ihn bereits weitergeleitet hatte – über einen Tunnel, einen Reverse-Proxy, eine SSH-Weiterleitung oder die eigene Portweiterleitungsfunktion eines Editors, so The Hacker News; die Notiz der Cloud Security Alliance listet dieselbe Auswahl auf. Wo diese Vorbedingung erfüllt war, heißt es in der Warnmeldung von VulnCheck, konnte ein Aufrufer ohne Anmeldeinformationen Sitzungen erstellen, beliebige Befehle ausführen und gespeicherte Gesprächstranskripte exfiltrieren. The Hacker News ergänzt, dass dieselbe Schnittstelle eine Anfrage bediente, die das gesamte Protokoll einer Sitzung herunterlädt.

Der Sandbox-Pfad benötigt eine andere Voraussetzung: Text, den der Agent liest und auf den er reagiert. Die Notiz der Cloud Security Alliance beschreibt einen eingeschränkten Agenten, der einen vom Angreifer gelieferten Prompt verarbeitet, der in einem Codekommentar, einer README-Datei oder einem Issue-Text eingebettet ist. Keiner der beiden Pfade erfordert einen gestohlenen Schlüssel, und die Notiz stellt fest, dass der Remote-Pfad keinerlei Interaktion mit dem Modell benötigt, sobald der Port exponiert ist.

Die exponierte Population umfasst daher alle, die die {{1}}Harness{{/1}} in Version 0.1.1-rc.2 oder früher mit Standardeinstellungen ausgeführt haben – eine Menge, auf die die Anzahl der Sterne nur hindeutet. The Hacker News zählte am 9. September 2026 mehr als {{2}}216.000 Sterne{{/2}} und gab zu bedenken, dass ein Stern ein Lesezeichen und keine Installation ist.

Was gilt als gesichert und was nicht

Aus dem CVE-Eintrag selbst geht hervor: VulnCheck ist die für die Nummerierung zuständige Stelle, reservierte die Kennung am 29. August 2026 und veröffentlichte den Eintrag am 8. September um 16:59 UTC; die Schwachstelle ist CWE-807; der betroffene Bereich umfasst alle Versionen vor 0.1.2-alpha.1; und die Anerkennung gilt Nir Zadok und Moshe Siman Tov Bustan. Die beiden im Eintrag enthaltenen Bewertungen – 9,4 nach CVSS 4.0 und 9,6 nach CVSS 3.1 – stammen von VulnCheck und nicht von einer zweiten, unabhängigen Bewertungsstelle – NVD führt beide Metriken mit VulnCheck als Quelle auf –, sodass es sich um eine einzige Bewertung handelt, die in zwei Frameworks ausgedrückt wird, und nicht um zwei übereinstimmende Bewertungen.

Aus dem Repository ermittelt: Der Fix-Commit 3e24087 mit dem Titel „fix(web): authenticate the browser Host API“ ist auf den 24. August 2026 datiert und fügt laut der GitHub-API ein Browser-Auth-Modul zusammen mit 210 Zeilen End-to-End-Tests für den neuen Ablauf hinzu. Das Release mit dem Tag dsh-v0.1.2-alpha.1 folgte am 27. August um 17:06 UTC.

Nicht belegt: Ausnutzung. Weder der CVE-Eintrag noch der Sicherheitshinweis von VulnCheck noch die Versionshinweise von DeepSeek beschreiben eine Ausnutzung in der Praxis, und NVD führt die Exploit-Reife als nicht definiert. Das EPSS-Modell von FIRST veranschlagte für die Schwachstelle eine Wahrscheinlichkeit von 1,24 % für eine Ausnutzung in den folgenden 30 Tagen, beim 68,9. Perzentil, in dem Feed vom 27. Oktober 2026. Das Archiv verzeichnet für diesen Eintrag keinen realen Schaden und bewertet ihn mit Konfidenz A, gut dokumentiert, wobei die Primärquellen übereinstimmen.

Die Termine, einschließlich zweier Berichte, die zuerst kamen.

Zwei Entwickler kamen zu derselben Schlussfolgerung, bevor es eine CVE gab, auf die man hätte verweisen können. The Hacker News berichtet über einen Beitrag im eigenen Diskussionsforum des Projekts vom 13. August 2026, der zeigt, wie ein weiterhin von der Sandbox eingeschränkter Prozess die lokale Schnittstelle erreichte und die Sitzung auf danger-full-access umschaltete, samt Testausgabe, sowie über einen zweiten Beitrag vom 14. August, der die Anfragen auflistet, die diese Schnittstelle ohne Authentifizierungsdaten akzeptierte. Der zweite Beitrag merkte außerdem an, dass das Projekt keine Datei mit Sicherheitsrichtlinie und keinen vertraulichen Meldeweg für Sicherheitslücken hatte; The Hacker News prüfte am 9. September und stellte fest, dass die Datei mit der Sicherheitsrichtlinie weiterhin fehlte.

Die Zeitlinie von OX Security setzt seinen Bericht an VulnCheck auf den 24. August 2026 — dasselbe Datum, das GitHub für den Fix-Commit verzeichnet. Die Commit-Nachricht sagt nichts über den Bericht, und die öffentliche Darstellung von OX Security, wie The Hacker News sie beschreibt, erwähnt die früheren Community-Beiträge nicht. Ob die beiden Ereignisse am 24. August in Zusammenhang standen, geht aus den öffentlichen Aufzeichnungen nicht hervor, und dieser Artikel setzt dies nicht voraus.

Die Zeitspanne zwischen Behebung und Offenlegung ist nicht ungewöhnlich. Die Notiz der Cloud Security Alliance hält fest, dass OX Security die Behebung am 30. August bestätigte, neun Tage bevor VulnCheck die CVE veröffentlichte.

Wo der Fix umgesetzt wurde – und wo nicht

Das GitHub-Tag und die Paketregistry wurden nicht gemeinsam aktualisiert, und genau das ist wichtig zu wissen, wenn man das Harness so installiert hat, wie es die Anleitung nahelegt. Das Kommandozeilenpaket @deepseek-ai/dsh wurde am 21. August 2026 in Version 0.1.1-rc.2 veröffentlicht und danach bis 0.1.2-alpha.2 am 30. August nichts mehr. Version 0.1.2-alpha.1, die in der CVE als Fix genannt wird, fehlt in der Registry vollständig, sodass die erste installierbare korrigierte Version dem Fix drei Tage hinterherlief. Die npm-Registry-Metadaten wurden für diesen Artikel am 28. Oktober 2026 gelesen; The Hacker News berichtete am 9. September über dieselbe Lücke.

Die Versionshinweise stellten es nicht als Sicherheitsrelease dar. Sie führen unter Routineänderungen auf, dass die Weboberfläche nun für den Netzwerkzugriff eine Einmal-Token-Authentifizierung verlangt, ohne CVE-Referenz und ohne Sicherheitshinweis, und The Hacker News fand am 9. September keine Sicherheitsmitteilung in der Advisory-Liste des Repositorys. Der Mechanismus, wie die Cloud Security Alliance ihn beschreibt: Das Harness gibt beim Start ein Einmal-Token aus, der Browser tauscht dieses Token gegen ein signiertes Cookie ein, und jeder nachfolgende Aufruf muss das Cookie vorlegen – das Vertrauen ist an ein beim Prozessstart ausgegebenes Geheimnis gebunden statt an einen behaupteten Netzwerkursprung.

Builds von Drittanbietern sind der offene Punkt. Desktop-Wrapper liefern ihre eigene Kopie des Harness mit, welche Version ein Nutzer also ausführt, liegt im Ermessen des Wrapper-Maintainers; The Hacker News fand einen Windows-Build, der Ende August auf 0.1.1-rc.2 festgelegt war und am 6. September auf 0.1.3-alpha.1 umgestellt wurde, die den Fix enthält.

Die Sandbox selbst ist unverändert. Beim Lesen der Befehlszeilenreferenz zu 0.1.2-rc.1 stieß The Hacker News auf dieselbe Aussage, dass Lesezugriffe und Netzwerkzugriff nicht eingeschränkt sind, und stellte fest, dass die Shell des Agenten weiterhin die Schnittstellenadresse erhält. Keine Quelle in dieser Berichterstattung sagt, ob ein Agent, der in seinem Arbeitsbereich arbeitet, unter dem neuen Schema noch eine gültige Sitzung erhalten kann – eine Frage, die die Dokumentation des Patches selbst offen lässt.

Was die Quellen des Datensatzes empfehlen

• Betrachten Sie jede Installation von 0.1.1-rc.2 oder früher als betroffen, unabhängig davon, wie sie paketiert wurde, einschließlich einer Kopie, die in einen Desktop-Wrapper eingebettet ist.

• Installieren Sie 0.1.2-alpha.2 oder neuer von npm; die neueste Version im Registry war am 27. Oktober 2026 0.2.2-alpha.2.

Wenn Sie kein Upgrade durchführen können, stoppen Sie die Weboberfläche, wenn sie nicht verwendet wird, und entfernen Sie alle Tunnel, Proxys oder Portweiterleitungen, die Port 3080 erreichen.

• Prüfen Sie, ob Port 3080 von anderen Stellen als Loopback aus erreichbar ist – einschließlich Container-Portweiterleitung, Reverse-Proxys und SSH-Tunneln.

• Protokollieren Sie Privilegieneskalationen und Änderungen des Genehmigungsmodus auf Harness-Ebene, denn der Angriff funktionierte, indem er eine nicht autorisierte Eskalation wie Routineaktivität aussehen ließ.

Alle fünf stammen aus der Mitteilung der Cloud Security Alliance und der Berichterstattung von The Hacker News; der CVE-Eintrag selbst enthält über die korrigierte Version hinaus keine Hinweise zur Behebung.

Warum die Cloud Security Alliance es als Muster liest

Die Mitteilung der Cloud Security Alliance stellt diese CVE neben zwei weitere Containment-Fehler bei Coding-Agenten, die sie 2026 dokumentierte: GuardFall am 1. Juli, bei dem zehn von elf populären Open-Source-Coding-Agenten dazu gebracht werden konnten, Shell-Befehle auszuführen, die ihre Guardrails blockieren sollten, sowie die Trust-Handoff-Befunde vom 22. Juli, bei denen ein eingeschränkter Agent eine Datei schrieb, die eine vertrauenswürdige Komponente außerhalb der Sandbox später ausführte. Die Mitteilung stellt ausdrücklich klar, dass alle drei auf eigenen Untersuchungen beruhen und nicht auf einer umfassenden Marktübersicht, und dass nicht geklärt ist, ob sich das Muster über die von ihr untersuchten Agenten hinaus verallgemeinern lässt. Sie argumentiert jedoch, dass die Fehler auf unterschiedlichen Ebenen liegen – Befehls-Guardrails, Downstream-Vertrauen und nun die Control-Plane-Authentifizierung –, und empfiehlt deshalb, Sandbox-Architektur als Beschaffungsfrage zu behandeln statt als bereits erfüllte Anforderung.

Die eigene Sicherheitsdokumentation von DeepSeek widerspricht dieser Lesart nicht. In der SAFETY.md des Repositorys heißt es, die Software „wurde keinem Sicherheitsaudit unterzogen und darf nicht als sicher oder produktionsreif betrachtet werden“, und dass Sandboxing, Genehmigungsaufforderungen und Berechtigungskontrollen „keine Isolation garantieren und keine Schäden verhindern“. Die Authentifizierungslücke, die es einem Agenten ermöglichte, über die Steuerungs-API nach außen zu gelangen, ist in aktuellen Builds geschlossen. Die Asymmetrie, die den Ausbruch kurz machte – eine Grenze um Schreibvorgänge und nichts um das Netzwerk – bleibt eine erklärte Einschränkung der Sandbox und kein Defekt, den der Patch beheben sollte.