DeepSeek Harness CVE-2026-82533: en agent i en sandlåda inaktiverar sin egen sandlåda med ett enda kommando

VulnCheck publicerade CVE-2026-82533 den 8 september 2026: en kritisk autentiseringskringgående sårbarhet som gjorde att en AI-kodagent kunde stänga av sin egen sandlåda med ett enda shellkommando. Programvaran är DeepSeek Harness, DeepSeeks lokala runtime med öppen källkod för kodagenter, som Cloud Security Alliance säger fick ungefär 215 000 GitHub-stjärnor inom några veckor; allt före 0.1.2-alpha.1 påverkas. Den bedömde om en anropare var lokal utifrån anroparens egen Host-header, så en begäran kunde hävda att den kom från loopback. Eftersom dess sandlåda begränsade filskrivningar men inte loopback-nätverk, kunde en instängd agent anropa harnessens oautentiserade kontroll-API på port 3080 och växla sin session till danger-full-access med godkännanden avstängda. VulnCheck ger den 9,4, kritisk; ingen exploatering i verkligheten görs gällande. Posten är en del av ett offentligt dataset över AI-incidenter, och the Orca AI Incident Archive innehåller hela postuppsättningen, med datum, allvarlighetsgrader och källor för varje post.

Kontrollen som frågade en förfrågan vad den var

Den sårbara komponenten är harnessets lokala agentkontroll-API, den lilla HTTP-tjänst som webbgränssnittet och kommandoraden använder för att styra en pågående session. Enligt Cloud Security Alliances forskningsnotis av den 10 september 2026, som bygger på rapporten från OX Security, företaget som hittade felet, lyssnade tjänsten som standard på 127.0.0.1 port 3080 och fattade sitt förtroendebeslut i en funktion som notisen kallar isTrustedApiRequest. Funktionen läste HTTP-headern Host och beviljade åtkomst när värdet matchade ett loopback-namn som localhost eller 127.0.0.1. Ett Host-huvud är metadata som klienten skriver; det säger ingenting om varifrån TCP-anslutningen kom. The Hacker News rapporterar den 9 september 2026, med hänvisning till den berörda källan, att kontrollen aldrig tittade på anslutningens ursprung och att en kommentar i samma fil säger att kontrollen "is not an auth layer."

Det är hela CWE-807, tillit till opålitliga indata i ett säkerhetsbeslut, och det är vad VulnCheck publicerade post beskriver: en loopback-Host-header som tillhandahålls av klienten och accepteras i stället för att validera den faktiska TCP-anslutningens ursprung.

Det som förvandlade en dålig kontroll till en flyktväg var att ramverket räckte agenten dess egna nycklar. The Hacker News rapporterar att ramverket skickar adressen till kontrollgränssnittet och identifieraren för den aktuella sessionen till agentens skal, så ett kommando inte behöver hitta någon av dem. Sandlådan täckte samtidigt en kanal men inte den andra: kommandoradsreferensen för den berörda versionen säger att skrivningar med standardinställningen stannar inom arbetsytan och tillfälliga mappar, medan läsningar och nätverksåtkomst inte är begränsade.

Varför godkännandepromptar inte stoppade det

Ramverket hade visst godkännandepromptar, och de kringgicks inte så mycket som att de helt enkelt inte var tillämpliga. The Hacker News rapporterar att godkännande i den drabbade versionen bara begärdes när ett kommando efterfrågade bredare åtkomst än sessionen redan hade. Eskaleringsanropet efterfrågade inget sådant; det ändrade sessionens inställning. En agent som körde det gick över till ett läge som OX Security kallar danger-full-access, med godkännandepromptar inställda på aldrig, och fortsatte att köra som användaren som hade startat ramverket, helt utanför sandlådan.

OX Securitys bevis för gränsen var ett kontrollerat par. The Hacker News rapporterar att företaget körde två sessioner med identiska standardinställningar och gav båda samma kommando: sessionen som gjorde anropet skrev till en mapp utanför sin arbetsyta, och den andra blockerades.

Den andra vägen, och förutsättningen den behövde

Samma saknade kontroll blottade harness för anropare som aldrig befann sig i en sandlåda alls, men endast under ett villkor som standardkonfigurationen inte skapade. Kommandoraden vägrade binda API:et till alla nätverksgränssnitt, så porten gick bara att nå från andra håll om en användare redan hade vidarebefordrat den – via en tunnel, en omvänd proxy, en SSH-vidarebefordran eller enredigerarens egen portvidarebefordringsfunktion, enligt The Hacker News; Cloud Security Alliances notis listar samma uppsättning. Där det förvillkoret gällde, enligt VulnCheck:s rådgivning, kunde en anropare utan autentiseringsuppgifter skapa sessioner, köra godtyckliga kommandon och exfiltrera lagrade konversationstranskript. The Hacker News tillägger att samma gränssnitt betjänade en begäran som laddar ner en sessions hela logg.

Den sandlådade vägen kräver en annan förutsättning: text som agenten kommer att läsa och agera på. Cloud Security Alliance-noten beskriver en begränsad agent som hanterar en av angriparen tillhandahållen prompt inbäddad i en kodkommentar, en README-fil eller issue-text. Ingen av vägarna kräver en stulen nyckel, och noten konstaterar att den fjärrbaserade vägen inte kräver någon interaktion med modellen alls när väl porten är exponerad.

Den exponerade populationen är därför alla som körde harnessen i 0.1.1-rc.2 eller tidigare med standardinställningar, en grupp som antalet stjärnor bara antyder. The Hacker News räknade mer än 216 000 stjärnor den 9 september 2026 och varnade för att en stjärna är ett bokmärke snarare än en installation.

Vad som är fastställt, och vad som inte är det

Fastställt utifrån själva CVE-posten: VulnCheck är numreringsmyndighet, reserverade identifieraren den 29 augusti 2026 och publicerade posten den 8 september kl. 16:59 UTC; svagheten är CWE-807; det påverkade intervallet är alla versioner före 0.1.2-alpha.1; och erkännandet går till Nir Zadok och Moshe Siman Tov Bustan. De två poängen som posten anger, 9,4 enligt CVSS 4.0 och 9,6 enligt CVSS 3.1, kommer från VulnCheck och inte från en andra, oberoende bedömare — NVD listar båda mätvärdena med VulnCheck som källa — så de utgör en enda bedömning uttryckt i två ramverk, inte två bedömningar som stämmer överens.

Fastställt från arkivet: fix-commit 3e24087, med titeln "fix(web): authenticate the browser Host API", är daterad 24 augusti 2026, och enligt GitHub API lägger den till en webbläsarautentiseringsmodul tillsammans med 210 rader end-to-end-tester för det nya flödet. Utgåvan med taggen dsh-v0.1.2-alpha.1 följde den 27 augusti kl. 17:06 UTC.

Ej fastställt: använd. Varken CVE-posten, VulnChecks säkerhetsmeddelande eller DeepSeeks versionsinformation beskriver utnyttjande i det vilda, och NVD anger exploateringsmognad som inte definierad. FIRST:s EPSS-modell gav sårbarheten 1,24 % sannolikhet för utnyttjande under de följande 30 dagarna, vid 68,9:e percentilen, i flödet daterat 27 oktober 2026. Arkivet registrerar ingen verklig skada för denna post och betygsätter den med konfidens A, väl dokumenterad, med primärkällor som stämmer överens.

Datumen, inklusive två rapporter som kom först

Två utvecklare kom fram till samma slutsats innan det fanns någon CVE att peka på. The Hacker News rapporterar om ett inlägg på projektets eget diskussionsforum den 13 augusti 2026 som visar en process som fortfarande är begränsad av sandlådan nå det lokala gränssnittet och byta sessionen till danger-full-access, med testutdata, och ett andra inlägg den 14 augusti som listar de förfrågningar som gränssnittet accepterade utan autentiseringsuppgifter. Det andra inlägget noterade också att projektet saknade en säkerhetspolicyfil och en privat kanal för att rapportera en sårbarhet; The Hacker News kontrollerade den 9 september och fann att säkerhetspolicyfilen fortfarande saknades.

OX Securitys tidslinje anger att deras rapport till VulnCheck lämnades den 24 augusti 2026 – samma datum som GitHub anger för åtgärdscommiten. Commit-meddelandet säger ingenting om rapporten, och OX Securitys offentliga redogörelse, såsom The Hacker News beskriver den, nämner inte de tidigare gemenskapsinläggen. Huruvida de två händelserna den 24 augusti hängde samman är inte något som de offentliga uppgifterna anger, och den här artikeln utgår inte från det.

Tidsglappet mellan åtgärd och offentliggörande är inte ovanligt. I Cloud Security Alliance-noten anges att OX Security bekräftade rättelsen den 30 augusti, nio dagar innan VulnCheck publicerade CVE.

Där fixen landade, och där den inte gjorde det

GitHub-taggen och paketregistret följdes inte åt, och det är det som är värt att veta om du installerade harnessen på det sätt som dess instruktioner föreslår. Kommandoradspaketet @deepseek-ai/dsh publicerade 0.1.1-rc.2 den 21 augusti 2026 och sedan inget förrän 0.1.2-alpha.2 den 30 augusti. Version 0.1.2-alpha.1, den som CVE:n anger som rättningen, saknas helt i registret, så den första installerabara rättade utgåvan kom tre dagar efter rättningen. npm-registrets metadata lästes för den här artikeln den 28 oktober 2026; The Hacker News rapporterade samma lucka den 9 september.

Versionsinformationen beskrev det inte som en säkerhetsutgåva. Bland rutinändringarna anger de att webbgränssnittet nu kräver autentisering med engångstoken för nätverksåtkomst, utan CVE-referens och utan säkerhetsmeddelande, och The Hacker News hittade ingen säkerhetsbulletin på repots rådgivningslista den 9 september. Mekanismen, så som Cloud Security Alliance beskriver den: harnessen skriver ut en engångstoken vid start, webbläsaren byter den token mot en signerad cookie, och varje efterföljande anrop måste presentera cookien – förtroendet är knutet till en hemlighet som utfärdas vid processens start i stället för till ett påstått nätverksursprung.

Tredjepartsbyggen är den lösa tråden. Skrivbordswrappers levererar sin egen kopia av ramverket, så vilken version en användare kör är wrapperunderhållarens val; The Hacker News hittade ett Windows-bygge som var låst till 0.1.1-rc.2 i slutet av augusti och som den 6 september flyttades till 0.1.3-alpha.1, vilken innehåller rättningen.

Sandlådan i sig är oförändrad. När The Hacker News läste kommandoradsreferensen för 0.1.2-rc.1 fann man samma formulering att läsning och nätverksåtkomst inte är begränsade, och fann att agentens skal fortfarande tar emot gränssnittsadressen. Ingen källa i den rapporteringen säger huruvida en agent som arbetar inom sin arbetsyta fortfarande kan få en giltig session under det nya upplägget, en fråga som patchningens egen dokumentation lämnar öppen.

Vad postens källor rekommenderar

• Behandla varje installation av 0.1.1-rc.2 eller tidigare som påverkad, oavsett hur den paketerades, inklusive en kopia inbäddad i ett skrivbordsskal.

• Installera 0.1.2-alpha.2 eller senare från npm; den nyaste versionen i registret den 27 oktober 2026 var 0.2.2-alpha.2.

• Om du inte kan uppgradera, stoppa webbgränssnittet när det inte används och ta bort alla tunnlar, proxyservrar eller portvidarebefordringar som når port 3080.

• Kontrollera om port 3080 är nåbar från någon annanstans än loopback, inklusive containerportvidarebefordran, omvända proxyservrar och SSH-tunnlar.

• Logga behörighetseskaleringar och ändringar av godkännandeläget på harness-nivå, eftersom attacken fungerade genom att få en obehörig eskalering att se ut som rutinmässig aktivitet.

Alla fem kommer från Cloud Security Alliance-noten och The Hacker News rapportering; själva CVE-posten innehåller ingen åtgärdsvägledning utöver den fixade versionen.

Varför Cloud Security Alliance tolkar det som ett mönster

Cloud Security Alliance-noten placerar denna CVE vid sidan av två andra containment-fel för kodagenter som den dokumenterade 2026: GuardFall den 1 juli, där tio av elva populära kodagenter med öppen källkod kunde förmås att köra skalkommandon som deras skyddsräcken var byggda för att blockera, och trust-handoff-fynden den 22 juli, där en begränsad agent skrev en fil som en betrodd komponent utanför sandlådan senare körde. Noten är tydlig med att alla tre kommer från dess egen forskning snarare än från en uttömmande undersökning av marknaden, och att det inte är fastställt om mönstret generaliserar bortom de agenter den undersökte. Det den argumenterar för är att felen ligger på olika lager – kommandoskyddsräcken, nedströms förtroende och nu autentisering i kontrollplanet – och det är därför den rekommenderar att behandla sandlådearkitektur som en upphandlingsfråga i stället för ett uppfyllt krav.

DeepSeeks egen säkerhetsdokumentation motsäger inte den tolkningen. Repositoriets SAFETY.md anger att programvaran "inte har genomgått en säkerhetsgranskning och inte får behandlas som säker eller produktionsklar", och att sandboxning, godkännandeprompter och behörighetskontroller "inte garanterar isolering eller förhindrar skada". Autentiseringsluckan som lät en agent ta sig ut genom kontroll-API:et är stängd i aktuella byggen. Asymmetrin som gjorde utträdet kort – en gräns kring skrivningar och ingenting kring nätverket – kvarstår som en angiven begränsning i sandlådan snarare än en defekt som patchen var avsedd att åtgärda.