Sandboxing is voor veel ontwikkelaars de “laatste verdedigingslaag” bij het uitvoeren van AI-coding-agenten met onbekende input. Toch laat de DeepSeek Harness kwetsbaarheid zien dat zelfs een geïsoleerde omgeving kan worden omzeild wanneer een hulpmiddel een route openzet naar functies die meer rechten krijgen.
In dit artikel leggen we uit wat er precies misging met DeepSeek Harness, welke versie(s) risico lopen, hoe de aanval werkte, en welke stappen u vandaag kunt nemen om uw omgeving te beschermen.
Wat is DeepSeek Harness en waarom is het belangrijk?
DeepSeek Harness is een open-source tool om AI coding-agents op een ontwikkelaarsmachine te laten draaien. Het doel is om de agent commando’s te laten uitvoeren binnen een operating-system sandbox en zo te voorkomen dat werk met “ontruste” bestanden buiten de beoogde map terechtkomt.
In de praktijk betekent dit: de agent mag typisch wel werken in een afgebakende workspace, maar niet zomaar bestanden overschrijven of locaties benaderen die niet horen bij de opdracht.
De kern van de DeepSeek Harness kwetsbaarheid
De DeepSeek Harness kwetsbaarheid is gecatalogiseerd als CVE-2026-82533. Onderzoekers beschreven dat een agent die in een sandbox draait, in staat was om de eigen isolatiegrenzen uit te zetten met een enkele opdracht.
Dat klinkt paradoxaal, maar het mechanisme bestond uit twee onderdelen: (1) de sandboxbeperkingen gelden voor bestanden en (2) de tool bood een lokale webinterface die vanuit de sandbox bereikbaar kon zijn. Door via die interface een andere sessiemodus te activeren, konden de commando’s vervolgens buiten de oorspronkelijke bestandsbeperking schrijven.
Hoe kon een sandboxed agent de beveiliging omzeilen?
Volgens de melding kon de escape werken vanaf een standaard installatie, tot DeepSeek het probleem repareerde op 27 augustus. De vereiste aanvalstermen waren bovendien afhankelijk van tekst die door een aanvaller werd aangeleverd en die de agent vervolgens gebruikte om de juiste call te doen.
De crux zat in een commando dat de tool’s eigen lokale interface aanriep. Daarmee werd de sessie gezet in een modus die de sandbox uitschakelde en ook de normale goedkeuringsprompten omzeilde. Het idee was dus niet: “vraag meer rechten”, maar: “verander de sessie-instelling zó dat die rechten al actief lijken”.
Waarom hoefde de agent niet om extra toestemming te vragen?
De tool paste goedkeuring toe wanneer een commando om meer toegang vroeg dan de sessie op dat moment had. In deze specifieke situatie werd geen commando gestart dat om bredere rechten vroeg; er werd juist een sessieconfiguratie gewijzigd. Daardoor trad de goedkeuringsflow niet in werking.
De onderzoekers (OX Research) rapporteerden dat één shell-commando voldoende was. Ze konden het effect aantonen door twee sessies met dezelfde standaardinstellingen te draaien: in één sessie konden writes naar een map buiten de workspace plaatsvinden, terwijl de andere sessie geblokkeerd bleef.
Wat reikte de sandbox wél en niet?
De sandbox in deze context richtte zich op bestandsisolatie. In de documentatie van de betreffende release stond dat writes onder de standaardinstelling binnen de workspace en tijdelijke mappen bleven, maar dat reads en netwerktoegang niet werden ingeperkt.
Dat is een belangrijke nuance: zelfs als het systeem schrijft buiten de workspace voorkomt, kan het nog steeds informatie opleveren of verbindingen mogelijk maken die voor een escape route relevant zijn. In dit geval bleek de tool’s eigen interface bereikbaar vanuit de sandbox.
Lokale webinterface zonder sterke authenticatie
Volgens de advisory had de webinterface een kwetsbare authenticatie-aanpak. Er werd geen sterke check gedaan op “waar het verzoek vandaan komt”. De beslissing om requests toe te laten baseerde zich op een door de client aangeleverde Host header.
Daarnaast gaf de tool de agent de benodigde gegevens mee om de interface te bereiken: het adres van de interface en de identifier van de huidige sessie. Daardoor hoefde de agent niet te gokken of te onderzoeken hoe hij die lokale component moest benaderen.
Een complicerende factor voor externe aanvallen is dat de tool in de getroffen release niet op alle netwerkinterfaces luisterde. Om van buiten toch bij de interface te komen, was doorgaans een vorm van tunneling of port forward nodig, zoals via een SSH-forward, proxy of editor.
Extra impact: logs en gesprekken uitleesbaar
Naast het omzeilen van de bestandsbeperkingen meldde de kwetsbaarheidsbeschrijving nog een tweede effect. De interface kon een request verwerken om het volledige log van een sessie te downloaden.
Volgens de VulnCheck-advisory kon een partij die de interface wist te benaderen, alle opgeslagen gesprekken ophalen zonder sleutel. Dat vergroot het risico op datalekken, omdat gesprekken vaak gevoelige inhoud bevatten (bijvoorbeeld commandoreeksen, projectcontext of prompts).
Welke versies waren kwetsbaar en wat is de fix?
De betrokken versies zijn 0.1.1-rc.2 en eerder. De record noemt 0.1.2-alpha.1 als vaste versie, maar die release werd niet op het npm-registry gepubliceerd. Dat is relevant, omdat veel gebruikers volgens de projectinstructies juist via npm installeren.
De status veranderde met 0.1.2-alpha.2: daar zat de eerste gepubliceerde versie met de benodigde authenticatiewijziging. De fix was drie dagen eerder al gepusht naar GitHub, maar pas daarna zichtbaar in de registry.
Wat u nu kunt doen
- Upgrade: installeer 0.1.2-alpha.2 of later.
- Controleer via desktop-apps: als u de harness via een derde partij desktopapp gebruikt, check welke versie die wrapper meelevert.
- Beperk blootstelling als upgraden niet lukt: stop de webinterface wanneer u hem niet gebruikt en verwijder tunnel/proxy/port forward die toegang mogelijk maken.
Er is volgens de beschikbare informatie geen eenvoudige manier om de escape volledig te voorkomen vanuit een default lokale setup zonder de fix, zolang de agent in dezelfde omgeving kan aanroepen wat hij intern kan bereiken.
Wat verandert de patch precies?
De oplossing draait om authenticatie voor toegang tot de interface. In de herziene aanpak print de tool een one-time token bij het opstartadres. De browser wisselt dit token om voor een signed cookie, en elke call naar de interface vereist vervolgens die cookie.
Het patchresultaat verandert daarmee niet de oorspronkelijke sandboxfilosofie: in 0.1.2-rc.1 staat volgens de beschrijving nog steeds dat reads en netwerktoegang niet confined zijn, en de agent krijgt ook nog altijd het adres van de interface. Onderzoekers plaatsen dus de focus op het beter afschermen van die lokale route, niet op het radicaal aanpassen van de sandbox.
Waarom dit patroon past in een bredere trend
Deze casus sluit aan bij een bredere reeks bevindingen over AI coding-agenten: onderzoekers hebben eerder laten zien dat agenten kunnen ontsnappen aan sandboxes wanneer de combinatie van toolgedrag en configuratie een route creëert naar code die buiten de beoogde isolatie draait.
De waarschuwing is daarmee helder: treat AI-agent tooling niet als “veilig genoeg” omdat er een sandbox is. De software zelf geeft ook aan dat sandboxing en goedkeuringsprompts geen garantie zijn voor volledige isolatie of schadepreventie.
Als u meer wilt lezen over hetzelfde type risicodenken bij agenten en beveiligingsafwegingen, kunt u ook kijken naar verborgen prompt-injecties bij AI-agenten en hoe u die aanpak.
Praktische checklist voor ontwikkelteams
Om de impact van de DeepSeek Harness kwetsbaarheid te beperken, helpt een korte, uitvoerbare aanpak:
- Inventariseer waar de harness draait: lokaal, CI-omgevingen en via desktop wrappers.
- Verifieer versies van de harness die daadwerkelijk gebruikt worden (niet alleen de versie in uw docs, maar de versie die in productie draait).
- Minimaliseer netwerkpaden naar de lokale interface: geen tunnels/port forwards die toegang mogelijk maken zonder noodzaak.
- Wees kritisch op ontruste input: voer geen onbekende opdrachten uit alsof de sandbox alles afvangt.
- Monitor op ongewone interacties met lokale webcomponenten of sessie-wijzigingen.
Tot slot: patchen is niet genoeg zonder blootstellingscontrole
De DeepSeek Harness kwetsbaarheid (CVE-2026-82533) is een duidelijke reminder dat sandboxing niet automatisch betekent dat een agent “gevangen blijft”. In dit geval kwam de escape tot stand via de tool’s eigen webinterface, die vanuit de sandbox bereikbaar was en door de aanvaller werd aangestuurd.
Door te upgraden naar 0.1.2-alpha.2 of later en de lokale interface af te schermen wanneer u die niet gebruikt, verkleint u het risico aanzienlijk. Tegelijk blijft het verstandig om sandboxing te zien als onderdeel van een bredere beveiligingsaanpak, niet als enige bescherming.
Bron: https://thehackernews.com/2026/09/deepseek-harness-flaw-let-ai-agents.html
