DeepSeek Harness: KI-Agent kann eigene Sandbox abschalten
9. Oktober 2026

Eine kritische Lücke ließ einen eingeschränkten KI Agenten seine Schutzumgebung selbst abschalten. Betroffene Installationen sollten mindestens auf Version 0.1.2-alpha.1 wechseln.
Worum es geht
Sicherheitsforscher von OX Security haben am 9. Oktober 2026 technische Details zu einer kritischen Lücke in DeepSeek Harness veröffentlicht. Das offene Werkzeug führt Befehle von Coding Agenten in einer Betriebssystem Sandbox aus. Genau diese Schutzschicht konnte ein eingeschränkter Agent jedoch über die lokale Steuerungs API des Programms abschalten. Die Schwachstelle trägt die Kennung CVE-2026-82533 und wird im CVE Datensatz mit 9,4 von 10 Punkten nach CVSS 4.0 bewertet.
Betroffen sind Versionen vor 0.1.2-alpha.1. DeepSeek veröffentlichte die korrigierte Version bereits am 27. August 2026. Die neue Veröffentlichung ist deshalb keine Meldung über eine ungepatchte Zero Day Lücke, sondern eine technische Aufarbeitung mit einem klaren Handlungsbedarf für Installationen, die noch eine ältere Vorschauversion nutzen.
Was DeepSeek Harness tatsächlich macht
DeepSeek Harness ist eine offene Laufzeitumgebung für KI Coding Agenten. Sie stellt eine Browseroberfläche bereit, verwaltet Sitzungen und lässt Agenten Werkzeuge wie eine Shell verwenden. Damit ein Modell nicht beliebig auf den Rechner zugreifen kann, sollen Betriebssystem Mechanismen wie Bubblewrap, Landlock oder Seatbelt Schreibzugriffe außerhalb des Arbeitsbereichs begrenzen.
Laut OX Security lauschte die lokale Agentensteuerung standardmäßig auf Port 3080 und verlangte keine Anmeldung. Sie entschied anhand des vom Client gesetzten Host Headers, ob eine Anfrage vertrauenswürdig war. Ein Prozess innerhalb der Sandbox konnte diesen Header selbst wählen, die lokale API aufrufen und seine Sitzung auf unbeschränkte Ausführung ohne weitere Freigabe umstellen. Die Sandbox blockierte zwar Dateizugriffe, ließ jedoch die Verbindung zur Loopback Adresse des Rechners offen.
War der Port durch einen Tunnel, eine Weiterleitung oder einen Reverse Proxy von außen erreichbar, beschrieb der CVE Datensatz zusätzlich Fernzugriffe auf Sitzungen, Befehle und gespeicherte Gesprächsverläufe. Die korrigierte Version prüft die Vertrauensgrenze anders; der verlinkte Patch und die Versionshinweise dokumentieren die Änderung.
Warum das wichtig ist
Coding Agenten besitzen oft genau die Zugriffe, die Angreifer interessieren: Quellcode, Paketregistrierungen, Cloud Werkzeuge, SSH Verbindungen und interne Dienste. Eine Sandbox soll verhindern, dass manipulierte Inhalte aus einem Repository, einer Webseite oder einer Fehlermeldung diese Berechtigungen übernehmen. Wenn der Agent die Schutzstufe über seine eigene Steuerungs API ändern kann, bricht diese Trennung an der entscheidenden Stelle.
Der Fall zeigt außerdem ein allgemeines Architekturproblem. Eine Adresse auf 127.0.0.1 ist nicht automatisch eine sichere Vertrauensgrenze. Prozesse auf demselben Rechner, eingeschlossene Werkzeuge und Port Weiterleitungen können lokale Dienste erreichen. Authentisierung, Prüfung der tatsächlichen Gegenstelle und eine getrennte Netzwerkumgebung bleiben nötig, selbst wenn eine Oberfläche nur lokal gedacht ist.
Einfach erklärt
Die Sandbox ist wie ein Hotelzimmer, in dem ein Gast bleiben soll. Die Rezeption prüfte aber nicht, wer anruft, sondern nur, ob der Anrufer behauptet, aus dem Hotel zu kommen. Der Gast konnte die interne Nummer wählen, sich als vertrauenswürdig ausgeben und sich selbst eine Generalkarte ausstellen. Das Update ersetzt diese bloße Behauptung durch eine belastbarere Prüfung.
Praktisches Beispiel
Eine Entwicklerin öffnet mit einer älteren Harness Version ein fremdes Repository. In einer Datei steckt eine Anweisung, die den Agenten zu einem unauffälligen Shell Befehl verleitet. Der Befehl erreicht die lokale API, setzt die Sitzung auf unbeschränkten Zugriff und deaktiviert Rückfragen. Ein späterer Werkzeugaufruf könnte dann außerhalb des Projektordners schreiben oder erreichbare Zugangsdaten auslesen.
Nach dem Wechsel auf Version 0.1.2-alpha.1 oder neuer soll genau dieser bekannte Weg geschlossen sein. Zusätzlich sollte die Entwicklerin prüfen, ob Port 3080 durch Entwicklungsumgebungen, SSH Weiterleitungen oder Proxys erreichbar gemacht wurde, und alte Sitzungen beziehungsweise gespeicherte Geheimnisse nach einem konkreten Verdacht untersuchen.
Einordnung und Grenzen
- OX Security demonstrierte einen funktionierenden Angriff, doch der öffentliche CVE Datensatz vermerkt bis zum 8. September 2026 keine bekannte Ausnutzung in freier Wildbahn. Ein Nachweis für breit angelegte Angriffe liegt damit nicht vor.
- Die Schwachstelle betrifft DeepSeek Harness vor 0.1.2-alpha.1. Sie belegt nicht, dass jede Sandbox für KI Agenten denselben Fehler besitzt. Andere Produkte brauchen eine eigene Prüfung.
- Ein Update schließt den beschriebenen Weg, ersetzt aber keine minimale Rechtevergabe. Agenten sollten keine dauerhaft geladenen Produktionsschlüssel erhalten, und lokale Steuerungsdienste sollten nicht ungeprüft weitergeleitet werden.
SEO und GEO Schlüsselbegriffe
DeepSeek Harness, CVE-2026-82533, Sandbox Escape, KI Agent Sicherheit, Coding Agent, Host Header, lokale API, Loopback Sicherheit, Prompt Injection, OX Security, CVSS 9.4, Version 0.1.2-alpha.1
💡 Im Klartext
Eine ältere Version von DeepSeek Harness ließ einen eingeschränkten KI Agenten seine eigene Schutzumgebung über eine lokale API abschalten. Wer das Werkzeug nutzt, sollte mindestens auf Version 0.1.2-alpha.1 aktualisieren und prüfen, ob der lokale Port weitergeleitet wurde.
Wichtigste Erkenntnisse
- →CVE-2026-82533 wird mit 9,4 von 10 Punkten nach CVSS 4.0 bewertet.
- →Ein Agent konnte über die lokale Steuerungs API seine Sandbox und Freigabeabfragen abschalten.
- →Betroffen sind Versionen vor 0.1.2-alpha.1; der Fix erschien am 27. August 2026.
- →Ein von außen erreichbarer Port konnte zusätzlich Sitzungen und gespeicherte Gesprächsverläufe offenlegen.
- →Der CVE Datensatz nennt keine bestätigte Ausnutzung in freier Wildbahn.
Häufige Fragen
Welche Version ist sicherer?
DeepSeek Harness 0.1.2-alpha.1 oder neuer enthält den veröffentlichten Fix für CVE-2026-82533.
Brauchte ein Angreifer ein Passwort?
Für den beschriebenen lokalen Weg waren laut OX Security keine Zugangsdaten nötig. Bei einem von außen erreichbaren Port galt das ebenfalls für die betroffene Schnittstelle.
Wurde die Lücke bereits ausgenutzt?
Der öffentliche CVE Datensatz nennt keine bestätigte Ausnutzung. Das schließt unbekannte Einzelfälle nicht aus.
Reicht das Update allein?
Es schließt den bekannten Weg. Zusätzlich sollten Nutzer Port Weiterleitungen, gespeicherte Geheimnisse und die Rechte des Agenten prüfen.