Een foutje in DeepSeek-harnasde open-sourcetool van DeepSeek voor het uitvoeren van AI-codeeragenten op de machine van een ontwikkelaar, laat een agent in een sandbox zijn eigen sandbox uitschakelen met één enkele opdracht.
De tool voert de opdrachten van een agent uit in een sandbox van het besturingssysteem, zodat een agent die aan niet-vertrouwde bestanden werkt, niet buiten zijn werkruimte kan schrijven. De agent zou die limiet kunnen opheffen door de eigen webinterface van de tool op dezelfde machine aan te roepen, en de opdrachten zouden dan buiten de sandbox worden uitgevoerd zonder een goedkeuringsprompt.
Het werkte op een standaardinstallatie totdat DeepSeek de tool op 27 augustus repareerde, en er was door de aanvaller aangeleverde tekst nodig die de agent las om hem te vragen de oproep te plaatsen.
De fout wordt bijgehouden als CVE-2026-82533. VulnCheck, die de identificatie heeft toegewezen, publiceerde het record op 8 september en beoordeelde de fout met een 9,4 op 10.
OX Research, het beveiligingsbedrijf dat de fout rapporteerde, zei dat één shell-commando voldoende was. De opdracht riep de lokale interface van het hulpprogramma aan en stelde de sessie van de agent in op een modus met de naam Danger-Full-Acces, die de sandbox uitschakelt en goedkeuringsprompts stopt.
Gewone bevelen hadden aanvankelijk geen goedkeuring nodig. Goedkeuring werd alleen toegepast als een opdracht om bredere toegang vroeg dan de sessie al had, en deze aanroep heeft hier niet om gevraagd. In plaats daarvan werd de instelling van de sessie gewijzigd.
OX zei dat het controleerde of de zandbak vóór de ontsnapping werkte. Het voerde twee sessies uit vanuit dezelfde standaardinstellingen en gaf beide dezelfde opdracht. De sessie die de oproep had gedaan, schreef naar een map buiten de werkruimte en de andere werd geblokkeerd.
De sandbox omvat alleen bestanden. De opdrachtregelreferentie voor de getroffen release zegt dat onder de standaardinstelling schrijfbewerkingen binnen de werkruimte en tijdelijke mappen blijven, terwijl ‘leesbewerkingen en netwerktoegang niet beperkt zijn’.
Hierdoor bleef de eigen interface van de tool bereikbaar vanuit de sandbox. De tool voorziet de shell van de agent ook van het adres van die interface en de identificatie van de huidige sessie, zodat de agent daar niet naar hoeft te zoeken.
De interface had geen authenticatie. In de betrokken release las de controle die bepaalde of een verzoek het verzoek kon bereiken de Host-header van het verzoek en keek nooit naar waar de verbinding vandaan kwam. In een opmerking in dat bestand staat dat de controle “geen auth-laag” is.
Die controle is wat het CVE-record beschrijft. Omdat het vertrouwde op een header die de client aanleverde, kon een externe machine beweren lokaal te zijn en de agent aansturen. De opdrachtregel van het hulpprogramma weigerde op alle netwerkinterfaces te luisteren, dus om de opdrachtregel van buitenaf te kunnen bereiken, moest de gebruiker de poort hebben doorgestuurd of geproxyd via een tunnel, een SSH-forward of een editor.
Dezelfde interface diende een verzoek in om het volledige logboek van een sessie te downloaden. Het advies van VulnCheck stelt dat een beller die de interface bereikt, alle opgeslagen gesprekken zonder sleutel kan ophalen.
Betrokken versies en wat u moet installeren
Versies 0.1.1-rc.2 en eerder worden beïnvloed. Het record noemt 0.1.2-alpha.1 als de vaste versie, maar die versie is nooit gepubliceerd in het npm-register, waar de eigen instructies van het project gebruikers naartoe sturen.
|
Versie |
Status |
Uitgegeven |
|---|---|---|
|
0.1.1-rc.2 en eerder |
Aangetast |
0.1.1-rc.2 gepubliceerd op 21 augustus |
|
0.1.2-alfa.1 |
Opgelost, alleen op GitHub |
27 augustus, niet op npm |
|
0.1.2-alfa.2 |
Eerste vaste release op npm |
30 augustus |
|
0,1,2-rc.1 |
Huidige NPM-release bevat de oplossing |
3 september |
The Hacker News controleerde het npm-register op 9 september en ontdekte dat de eerste gepubliceerde release met de authenticatiewijziging 0.1.2-alpha.2 is, drie dagen nadat de oplossing naar GitHub was gepusht.
- Installeer 0.1.2-alpha.2 of hoger. De huidige versie van het register is 0.1.2-rc.1.
- Als u de installatie via een desktop-app van derden hebt uitgevoerd, controleer dan welke versie van het harnas wordt meegeleverd.
- Als u niet kunt upgraden, stop dan de webinterface wanneer u deze niet gebruikt en verwijder alle tunnels, proxy’s of port forwards die deze bereiken.
Geen enkele bron die voor dit artikel is beoordeeld, biedt een manier om de ontsnapping vanuit de sandbox op een standaard lokale installatie te stoppen terwijl de tool actief is. Het rapport van 13 augustus zegt dat het beperken van het adres waarnaar de tool luistert niet helpt, omdat de agent al op dezelfde machine staat.
De oplossing geeft de interface een identiteitscontrole. De tool drukt nu een eenmalig token af op het opstartadres; de browser wisselt dat token uit voor een ondertekende cookie, en voor elke oproep naar de interface is de cookie vereist.
Wat de oplossing niet verandert, is de sandbox. In 0.1.2-rc.1 zegt dezelfde verwijzing nog steeds dat lees- en netwerktoegang niet beperkt zijn, en dat de shell van de agent nog steeds het interface-adres ontvangt. Geen enkele bron geeft aan of een agent die binnen zijn werkruimte draait nog steeds een geldige sessie kan verkrijgen onder het nieuwe schema.
Desktopbuilds van derden verzenden hun eigen kopie van het harnas, en welke kopie ze verzenden is de keuze van de wrapper-onderhouder. Eén Windows-build heeft eind augustus 0.1.1-rc.2 vastgezet en op 6 september verplaatst naar 0.1.3-alpha.1, dat de oplossing bevat. Iedereen die het harnas via een wrapper heeft geïnstalleerd, moet controleren welke versie het bevat.
Een harnas van codeermiddelen is de moeite waard om aan te vallen omdat het een schaal bevat. DeepSeek Harness voert de opdrachten van een agent uit onder het account waarmee deze is gestart.
In de eigen veiligheidsmededeling van het project staat dat de software geen beveiligingsaudit heeft ondergaan en dat sandbox- en goedkeuringsprompts “geen isolatie garanderen of schade voorkomen”. Het vertelt gebruikers dat ze niet op de tool moeten vertrouwen als hun enige beveiligingscontrole voor niet-vertrouwd werk.
De repository had op 9 september meer dan 216.000 sterren, een telling van accounts die er een bladwijzer van maakten in plaats van installaties.
Onderzoekers hebben dit jaar herhaaldelijk codeeragenten ontdekt die uit hun sandboxes ontsnapten, waaronder een reeks fouten waarbij de eigen configuratie van een repository ervoor zorgde dat agenten aanvallerscode buiten hun sandboxes uitvoerden.
Gemeenschapsrapporten beschreven dezelfde ontsnapping in augustus
Twee ontwikkelaars beschreven dezelfde ontsnapping op het eigen discussiebord van DeepSeek voordat de CVE bestond. Op 13 augustus plaatste iemand een rapport waaruit bleek dat een proces dat nog steeds door de sandbox wordt vastgehouden, de lokale interface bereikt en vervolgens de sessie overschakelt naar volledige toegang met gevaar, met testuitvoer.
Op 14 augustus plaatste een ander een rapport op dezelfde interface, met een opsomming van de verzoeken die het zonder enige inloggegevens accepteerde.
In dat tweede rapport werd ook opgemerkt dat het project geen beveiligingsbeleidsdossier had en geen privémanier om een fout te melden. Het project heeft nog steeds geen beveiligingsbeleidsbestand.
OX Research meldde de fout op 24 augustus aan VulnCheck, via zijn eigen tijdlijn, en VulnCheck crediteert Nir Zadok en Moshe Siman Tov Bustan. Het bericht van OX vermeldt de eerdere rapporten niet.
The Hacker News controleerde de advieslijst van de repository op 9 september en vond geen gepubliceerd beveiligingsadvies. De release waarin de oplossing werd aangebracht, vermeldt deze onder de routinematige wijzigingen, zoals het verwijderen van een oud transport en het vereisen van “eenmalige token-authenticatie voor netwerktoegang”, zonder beveiligingswaarschuwing en zonder vermelding van de CVE.
