Agent si vypnul vlastní sandbox jedním příkazem. Bez hesla, bez dotazu

Kódovací agent zavřený v sandboxu si ho jedním příkazem vypnul sám — na výchozím nastavení, bez hesla, bez schvalovacího dotazu. Chyba CVE-2026-82533 v nástroji DeepSeek Harness je zajímavá tím, čím není: není to chytrý útok na model. Je to obyčejná díra v ověřování, umocněná tím, že sandbox hlídal soubory a na síť zapomněl. A pokud vám vývojáři pouštějí agenta na firemní kód, je to přesně ten scénář, o kterém si myslíte, že ho máte pokrytý.

Co se stalo

• Co je DeepSeek Harness. Open-source nástroj DeepSeeku pro provoz kódovacích AI agentů na počítači vývojáře. Repozitář vznikl 13. srpna 2026 a dnes má přes 218 000 hvězd a 25 000 forků — během čtyř týdnů. Nástroj běží jako webové rozhraní nad lokálním HTTP API na 127.0.0.1:3080.
• Chyba. Podle záznamu v databázi GitHub Advisory obsahoval Harness před verzí 0.1.2-alpha.1 obcházení autentizace v lokálním řídicím API: „server ověřuje pouze hodnotu hlavičky Host dodanou klientem, nikoli skutečný původ TCP spojení." Útočník tak mohl volat privilegované příkazy commands/execute s oprávněním danger-full-access, přepnout schvalovací politiku sezení na neomezené spouštění a stáhnout všechny uložené konverzace bez jakéhokoli klíče.
• Hodnocení. CVSS 4.0 9,4 podle advisory VulnCheck (které je CNA), v záznamu GitHubu navíc CVSS 3.1 9,6. Kategorie CWE-807 — spoléhání na nedůvěryhodný vstup při bezpečnostním rozhodnutí. Nález hlásí Nir Zadok a Moshe Siman Tov Bustan.
• Proč to fungovalo zevnitř. Nálezci z OX Research popisují dvě podmínky, které se sešly. Sandbox omezoval zápis do souborů, ale síť nechal otevřenou: u bubblewrapu se předávalo --unshare-pid, ale ne --unshare-net, u macOS Seatbelt profil používal (allow default) a nad to jen (deny file-write*). Loopback tedy zůstal zevnitř dosažitelný. A druhá podmínka: běžné příkazy v shellu schválení nevyžadovaly — schvalovalo se jen navýšení oprávnění. Agent tak zavolal místní API, přepnul si sezení na danger-full-access a schvalování na „nikdy". V logu sezení není žádná událost approval/request a změna politiky je zapsaná jako source: {kind: 'user'} — nástroj nedokázal odlišit shell svého agenta od člověka u klávesnice.
• Kontrolní pokus. OX pustil dvě sezení ze stejného výchozího nastavení a dal jim tentýž příkaz. Sezení, které předtím provedlo ono jedno volání, zapsalo mimo svůj workspace; druhé sandbox zablokoval. To je podstatné — dokládá, že izolace předtím opravdu fungovala.
• Časová osa. 24. 8. nález potvrzen a nahlášen, 27. 8. oprava ve verzi 0.1.2-alpha.1, 30. 8. nálezci ověřili opravu, 8. 9. zveřejněno CVE. Opravný commit v repozitáři nese název „fix(web): authenticate the browser Host API".

Co jsem si ověřil sám a v přehledech to nebylo

Čtyři věci, které jsem našel až přímo v repozitáři a v registru npm — a které mění, co si z toho odnést.

• Opravená verze 0.1.2-alpha.1 na npm nikdy nevyšla. V registru npm je zranitelná 0.1.1-rc.2 publikovaná 21. 8., pak přeskok rovnou na 0.1.2-alpha.2 z 30. 8. Kdo se řídil číslem z CVE a hledal ho tam, kam ho posílá návod k instalaci, nenašel nic. Aktuální vydání pod značkou latest je dnes 0.1.5-rc.1, publikované 10. září ve 3:12 rána — projekt vydává novou verzi skoro každý den, což samo o sobě znamená, že „aktualizovali jsme to v srpnu" není odpověď.
• Oprava zavřela API, ne sandbox. Referenční příručka zranitelné verze říkala, že zápisy zůstávají ve workspace, ale „čtení a přístup k síti nejsou omezeny". Stejná věta je v dnešní příručce beze změny. Sandbox tedy dál nechrání před odesláním dat ven — chrání jen soubory na disku. Ta věta dnes navíc pokračuje upozorněním, že samostatný strom sdk-minimal má natvrdo danger-full-access a žádnou schvalovací službu nemá vůbec.
• Autoři věděli, že to není autentizace. Přímo v komentáři onoho souboru ve zranitelné verzi stojí: „this fence is not an auth layer". Kontrola hlavičky Host tam byla proti DNS rebindingu v prohlížeči — a proti tomu fungovala. Jen na ni nikdo neměl věšet oprávnění.
• Oprava sama má vlastnosti, o kterých je dobré vědět. Podle architektonické poznámky projektu se teď při startu vypíše jednorázový token v URL, ten se vymění za podepsanou cookie a tou se ověřuje každé volání. Poznámka ale sama upozorňuje: cookie platí ve výchozím nastavení 30 dní, nemá příznak Secure (server jede po nešifrovaném loopbacku), držení cookie opravňuje k celému API včetně spouštění příkazů, žádné odhlášení neexistuje a jediné globální odvolání je smazat záznam v $DSH_HOME/.credentials.yaml a restartovat proces. Startovní URL je tedy nově citlivý údaj — projekt to v té poznámce píše výslovně.

A jedna poznámka na okraj, která hodně vypovídá o povaze celého nástroje: poznámky k opravné verzi obsahují vedle opravy i změnu, kterou nikdo nekomentoval — „veřejný WebFetch je nově zapnutý ve výchozím stavu, se SSRF ochranou a bez schvalování jednotlivých požadavků". Ve stejném vydání se tedy jedna hranice zavřela a jiná povolila.

Proč se to týká i vás

Namítnete, že DeepSeek Harness u vás nikdo neprovozuje. Možná ano — ale ta chyba není o DeepSeeku. Je o třech předpokladech, které má ve firmě zabudované skoro každý, kdo dnes nasazuje agenty.

• „Je to na localhostu, takže je to bezpečné" už neplatí. Dokud u vás na počítači běželi jen lidé, byla lokální služba bez hesla přijatelný kompromis. Ve chvíli, kdy na témž stroji běží něco, co vykonává instrukce z cizího textu, je 127.0.0.1 uvnitř ohrožené zóny. Každé lokální API bez ověření — vývojářský nástroj, agent, ladicí port, správcovské rozhraní — je pro agenta dosažitelné.
• Sandbox pro soubory není sandbox. Když si od dodavatele necháte potvrdit, že „agent běží v sandboxu", zeptejte se konkrétně: co všechno ta izolace zahrnuje? Tady omezovala zápis na disk a síť nechala volnou — a přesně tou mezerou se to prolomilo. Stejnou otázku má smysl položit u kontejnerů, VM i u cloudových běhových prostředí.
• Schvalování, které se ptá jen na navýšení práv, nechrání před příkazem, kterým se práva navýší. To je v tomhle případě to nejelegantnější a nejnepříjemnější: mechanismus dělal přesně to, co měl v zadání, jen zadání mělo díru. Když někde máte „u citlivých operací se to zeptá", ověřte, jestli je změna nastavení citlivá operace.
• Odpovědnost je na vás, ne na nástroji. Bezpečnostní upozornění projektu na to jde rovnou: „DeepSeek Harness neprošel bezpečnostním auditem a nesmí být považován za bezpečný nebo připravený k produkčnímu nasazení" a „sandboxing, schvalovací dotazy a řízení oprávnění mohou riziko snížit, ale nezaručují izolaci". Doslovně tam stojí i věta „nespoléhejte na DeepSeek Harness jako na jediné bezpečnostní opatření pro nedůvěryhodné úlohy". Licence MIT vylučuje jakoukoli záruku. Kdo takový nástroj pustí na firemní repozitář, nese riziko sám — a mimochodem, tohle je ta část, kterou v posudku dodavatele nikdo nečte.

Co s tím

Žádný z těch kroků není projekt. Je to dopoledne s tím, kdo u vás spravuje vývojářské stanice.

• 1. Zjistěte, co si vývojáři nainstalovali. Ne „jaký nástroj schvalujeme", ale co skutečně běží. Kódovací agenty si lidé pořizují sami, mimo správu IT, a tenhle konkrétní projekt nasbíral 200 000 hvězd za měsíc. Když ho někdo má, potřebujete jen zkontrolovat verzi — pod 0.1.2-alpha.2 z npm je zranitelná.
• 2. U každého agenta si napište, co jeho izolace pokrývá. Tři sloupce: soubory, síť, procesy. Když u „síť" nemáte jasnou odpověď, máte tam stejnou mezeru jako tady. Vypnout agentovi odchozí síť úplně většinou nejde — pak alespoň vyjmenujte, kam smí.
• 3. Zavřete lokální porty vývojářských nástrojů před tunely a přesměrováním. Druhá útočná cesta v tomhle případě vyžadovala, aby byl port dostupný zvenčí — přes tunel, reverzní proxy, SSH forward nebo přesměrování v editoru. To si lidé zapínají kvůli pohodlí a pak na to zapomenou. Projděte, co je na strojích vývojářů vystrčené ven.
• 4. Berte prostředí kódovacího agenta jako prostředí s přístupem ke všemu, co má vývojář. SSH klíče, cloudové přihlašovací údaje, tokeny do registrů, interní systémy dosažitelné z té stanice. Odsud plyne jediné praktické opatření, které vydrží i příští chybu: agent má běžet na jednorázovém stroji nebo v odděleném profilu, ne v účtu, kde má člověk všechno.
• 5. Zapište si, že novinka není referenční implementace. Tenhle nástroj byl zranitelný po celou dobu své veřejné existence až do 27. srpna — tedy po celou dobu, kdy sbíral ty stovky tisíc hvězd. Počet hvězd na GitHubu není bezpečnostní ukazatel a u čerstvých projektů dokonce ukazuje opačným směrem.

A teď proti vlastnímu byznysu: jestli u vás „AI" znamená, že lidé používají ChatGPT nebo Copilot v prohlížeči, tenhle článek se vás netýká a není kvůli němu co řešit ani co objednávat. Popsané riziko vzniká výhradně tam, kde agent má shell a běží na stroji s firemními přístupy. A i tam je první krok kontrola verze, ne audit — na to nikoho nepotřebujete.

Kde to řeším s klienty

Nejčastější nález u firem, které agenty používají při vývoji, není chyba v modelu ani v promptu. Je to rozpor mezi tím, co si firma myslí, že její izolace pokrývá, a tím, co pokrývá doopravdy — přesně jako tady, kde „sandbox" znamenalo „sandbox na soubory". Zmapování toho, co váš agent smí, čím je to vynucené a co to udrží pod tlakem, dělám v rámci AI Act Readiness Auditu; když chcete jen vědět, jak na tom jste, začněte AI Risk Scanem zdarma. Volně to navazuje na starší text o tom, jak modely utíkají ze sandboxů při testech výrobců — s tím rozdílem, že tohle se nedělo v laboratoři, ale na výchozí instalaci u vývojáře.