DeepSeek Harness CVE-2026-82533: agent w piaskownicy wyłącza własną piaskownicę jednym poleceniem

VulnCheck opublikował CVE-2026-82533 8 września 2026 r.: krytyczne obejście uwierzytelniania, które pozwalało agentowi kodującemu AI wyłączyć własną piaskownicę jednym poleceniem powłoki. Oprogramowaniem jest DeepSeek Harness, otwartoźródłowy lokalny runtime DeepSeek dla agentów kodujących, który według Cloud Security Alliance zdobył około 215 000 gwiazdek GitHub w ciągu kilku tygodni; podatne są wszystkie wersje przed 0.1.2-alpha.1. Oprogramowanie oceniało, czy wywołujący jest lokalny, na podstawie własnego nagłówka Host wywołującego, więc żądanie mogło twierdzić, że pochodzi z interfejsu loopback. Ponieważ jego piaskownica ograniczała zapis plików, ale nie komunikację sieciową loopback, agent w piaskownicy mógł wywołać nieuwierzytelnione API sterujące harnessu na porcie 3080 i przełączyć swoją sesję na danger-full-access z wyłączonymi zatwierdzeniami. VulnCheck ocenia je na 9,4 (krytyczne); nie twierdzi się, że doszło do eksploatacji w rzeczywistym środowisku. Wpis ten jest jednym rekordem w publicznym zbiorze danych o incydentach AI, a Orca AI Incident Archive zawiera pełny zestaw rekordów, wraz z datami, ocenami ważności i źródłami dla każdego wpisu.

Sprawdzenie, które zapytało żądanie, czym ono było

Zranionym komponentem jest lokalne API sterowania agentem w harnessie — niewielka usługa HTTP, której interfejs webowy i wiersz poleceń używają do kierowania działającą sesją. Według notatki badawczej Cloud Security Alliance z 10 września 2026 r., która opiera się na opracowaniu OX Security, firmy, która znalazła lukę, usługa ta domyślnie nasłuchiwała na 127.0.0.1 na porcie 3080 i podejmowała decyzję o zaufaniu w funkcji, którą notatka nazywa isTrustedApiRequest. Funkcja odczytywała nagłówek HTTP Host i przyznawała dostęp, gdy wartość pasowała do nazwy pętli zwrotnej, takiej jak localhost lub 127.0.0.1. Nagłówek Host to metadane zapisywane przez klienta; nie mówi nic o tym, skąd pochodziło połączenie TCP. The Hacker News, powołując się na dotknięty problemem kod źródłowy 9 września 2026 r., donosi, że kontrola nigdy nie sprawdzała pochodzenia połączenia, a komentarz w tym samym pliku stwierdza, że kontrola „nie jest warstwą uwierzytelniania”.

To jest całość CWE-807 – poleganie na niezaufanych danych wejściowych przy podejmowaniu decyzji bezpieczeństwa – i to właśnie opisuje opublikowany rekord VulnCheck: dostarczony przez klienta nagłówek Host wskazujący na loopback, akceptowany w miejsce weryfikacji rzeczywistego źródła połączenia TCP.

To, co zamieniło wadliwą kontrolę w drogę ucieczki, to fakt, że harness przekazywał agentowi jego własne klucze. Hacker News donosi, że harness przekazuje powłoce agenta adres interfejsu sterowania i identyfikator bieżącej sesji, więc polecenie nie musi odkrywać żadnego z nich. Tymczasem sandbox obejmował jeden kanał, a nie drugi: dokumentacja referencyjna wiersza poleceń dla dotkniętej wersji mówi, że w domyślnym ustawieniu zapisy pozostają w obszarze roboczym i folderach tymczasowych, podczas gdy odczyty i dostęp do sieci nie są ograniczone.

Dlaczego monity o zatwierdzenie tego nie powstrzymały

Harness wprawdzie miał monity o zatwierdzenie, ale nie tyle je ominięto, ile nie miały zastosowania. Hacker News donosi, że w dotkniętym wydaniu zatwierdzenie było wymagane tylko wtedy, gdy polecenie próbowało uzyskać szerszy dostęp niż ten, który sesja już miała. Wywołanie eskalacji nie dążyło do niczego takiego; zmieniało ustawienie sesji. Agent, który je wykonał, przeszedł w tryb, który OX Security nazywa danger-full-access, z monitami o zatwierdzenie ustawionymi na „nigdy”, i działał dalej jako użytkownik, który uruchomił harness, całkowicie poza piaskownicą.

Dowodem OX Security na istnienie tej granicy była kontrolowana para. Hacker News podaje, że firma przeprowadziła dwie sesje z identycznymi ustawieniami domyślnymi i wydała obu to samo polecenie: sesja, która wykonała wywołanie, zapisała dane do folderu poza swoim obszarem roboczym, a druga została zablokowana.

Druga ścieżka i wymagany przez nią warunek wstępny

Ten sam brakujący mechanizm kontroli narażał harness na wywołania od podmiotów, które w ogóle nie znajdowały się w piaskownicy, ale tylko w warunku, którego konfiguracja domyślna nie tworzyła. Narzędzie wiersza poleceń odmawiało powiązania API ze wszystkimi interfejsami sieciowymi, więc port był osiągalny z zewnątrz tylko wtedy, gdy użytkownik już go przekierował — przez tunel, odwrotne proxy, przekierowanie SSH lub własną funkcję przekierowywania portów edytora, według The Hacker News; notatka Cloud Security Alliance wymienia ten sam zestaw. Gdy ten warunek wstępny był spełniony, jak stwierdza biuletyn VulnCheck, wywołujący bez poświadczeń mógł tworzyć sesje, wykonywać dowolne polecenia i eksfiltrować przechowywane transkrypty rozmów. The Hacker News dodaje, że ten sam interfejs obsługiwał żądanie, które pobiera cały dziennik sesji.

Ścieżka w piaskownicy wymaga innego warunku wstępnego: tekstu, który agent odczyta i na którym będzie działać. Nota Cloud Security Alliance opisuje agenta w ograniczonym środowisku, który przetwarza prompt dostarczony przez atakującego, osadzony w komentarzu do kodu, pliku README lub treści zgłoszenia. Żadna z tych ścieżek nie wymaga skradzionego klucza, a nota zauważa, że ścieżka zdalna nie wymaga żadnej interakcji z modelem, gdy tylko port zostanie wystawiony.

Narażona populacja to zatem każdy, kto uruchamiał harness w wersji 0.1.1-rc.2 lub wcześniejszej z domyślnymi ustawieniami — zbiór, który liczba gwiazdek jedynie z grubsza oddaje. The Hacker News naliczył ponad 216 000 gwiazdek 9 września 2026 r. i ostrzegł, że gwiazdka to zakładka, a nie instalacja.

Co jest ustalone, a co nie

Ustalono na podstawie samego rekordu CVE: VulnCheck jest organem numerującym, zarezerwował identyfikator 29 sierpnia 2026 r. i opublikował rekord 8 września o 16:59 UTC; słabością jest CWE-807; zakresem objętym podatnością jest każda wersja przed 0.1.2-alpha.1; a uznanie przypada Nirowi Zadokowi i Moshemu Simanowi Tovowi Bustanowi. Dwie oceny, które zawiera rekord — 9,4 w CVSS 4.0 i 9,6 w CVSS 3.1 — pochodzą od VulnCheck, a nie od drugiego, niezależnego podmiotu oceniającego — NVD podaje oba wskaźniki ze wskazaniem VulnCheck jako źródła — są więc jedną oceną wyrażoną w dwóch ramach, a nie dwiema zgodnymi ocenami.

Ustalono na podstawie repozytorium: commit poprawki 3e24087, zatytułowany „fix(web): authenticate the browser Host API”, jest datowany na 24 sierpnia 2026 r. i — według API GitHuba — dodaje moduł uwierzytelniania w przeglądarce wraz z 210 liniami testów end-to-end dla nowego przepływu. Wydanie oznaczone tagiem dsh-v0.1.2-alpha.1 nastąpiło 27 sierpnia o 17:06 UTC.

Nie ustalono: wykorzystanie. Ani rekord CVE, ani biuletyn VulnCheck, ani informacje o wydaniu DeepSeek nie opisują wykorzystania w rzeczywistym środowisku, a NVD odnotowuje dojrzałość exploitów jako niezdefiniowaną. Model EPSS FIRST przypisał tej podatności 1,24% prawdopodobieństwa wykorzystania w ciągu kolejnych 30 dni, na poziomie 68,9 percentyla, w strumieniu danych z 27 października 2026 r. Archiwum nie odnotowuje żadnych szkód w rzeczywistym świecie dla tego wpisu i ocenia go na poziomie zaufania A, dobrze udokumentowany, przy zgodnych źródłach pierwotnych.

Daty, w tym dwa raporty, które pojawiły się jako pierwsze.

Dwóch deweloperów doszło do tego samego wniosku, zanim istniał jakikolwiek CVE, na który można było wskazać. The Hacker News relacjonuje wpis na własnym forum dyskusyjnym projektu z 13 sierpnia 2026 r., pokazujący proces wciąż ograniczony przez piaskownicę, który dociera do lokalnego interfejsu i przełącza sesję na danger-full-access, wraz z wynikami testów, oraz drugi wpis z 14 sierpnia wymieniający żądania, które ten interfejs przyjął bez poświadczeń. Drugi wpis zauważał również, że projekt nie miał pliku polityki bezpieczeństwa ani prywatnej ścieżki zgłaszania błędów; The Hacker News sprawdził 9 września i stwierdził, że plik polityki bezpieczeństwa nadal nie istnieje.

Harmonogram firmy OX Security wskazuje, że jej raport do VulnCheck został złożony 24 sierpnia 2026 r. — ta sama data, którą GitHub odnotowuje dla commita poprawki. Komunikat commita nie mówi nic o raporcie, a publiczna relacja OX Security, jak opisuje ją The Hacker News, nie wspomina wcześniejszych postów społeczności. To, czy dwa wydarzenia z 24 sierpnia były powiązane, nie wynika z publicznego zapisu, a ten artykuł tego nie zakłada.

Odstęp między poprawką a ujawnieniem nie jest nietypowy. Notatka Cloud Security Alliance odnotowuje, że OX Security potwierdził poprawkę 30 sierpnia, dziewięć dni przed opublikowaniem CVE przez VulnCheck.

Gdzie poprawka trafiła, a gdzie nie

Tag na GitHubie i rejestr pakietów nie ruszyły się razem — i to jest ta część warta poznania, jeśli zainstalowałeś harness tak, jak sugerują jego instrukcje. Pakiet wiersza poleceń, @deepseek-ai/dsh, ukazał się w wersji 0.1.1-rc.2 21 sierpnia 2026 r., a potem nic aż do 0.1.2-alpha.2 30 sierpnia. Wersja 0.1.2-alpha.1, ta, którą CVE wskazuje jako poprawkę, jest całkowicie nieobecna w rejestrze, więc pierwsze instalowalne wydanie z poprawką pojawiło się trzy dni po samej poprawce. Metadane rejestru npm odczytano na potrzeby tego artykułu 28 października 2026 r.; The Hacker News doniósł o tej samej luce 9 września.

Notatki o wydaniu nie przedstawiały go jako wydania dotyczącego bezpieczeństwa. Wśród rutynowych zmian wymieniają, że interfejs webowy wymaga teraz uwierzytelniania jednorazowym tokenem przy dostępie sieciowym, bez odniesienia do CVE i bez komunikatu o bezpieczeństwie, a The Hacker News nie znalazł 9 września żadnej porady bezpieczeństwa na liście porad bezpieczeństwa repozytorium. Mechanizm, jak opisuje go Cloud Security Alliance: harness wypisuje jednorazowy token przy uruchomieniu, przeglądarka wymienia ten token na podpisane ciasteczko, a każde kolejne wywołanie musi przedstawić ciasteczko — zaufanie powiązane z sekretem wydanym przy starcie procesu, a nie z deklarowanym pochodzeniem sieciowym.

Kompilacje podmiotów trzecich to niezałatwiona sprawa. Nakładki desktopowe dostarczają własną kopię harnessu, więc to, którą wersję uruchamia użytkownik, zależy od wyboru opiekuna nakładki; The Hacker News znalazł jedną kompilację dla Windows przypiętą do 0.1.1-rc.2 pod koniec sierpnia, która 6 września przeszła na 0.1.3-alpha.1 zawierającą poprawkę.

Sama piaskownica pozostaje bez zmian. Czytając dokumentację interfejsu wiersza poleceń w wersji 0.1.2-rc.1, The Hacker News znalazł to samo stwierdzenie, że odczyty i dostęp do sieci nie są ograniczone, oraz odkrył, że powłoka agenta nadal otrzymuje adres interfejsu. Żadne źródło w tym materiale nie mówi, czy agent pracujący wewnątrz swojego obszaru roboczego może nadal uzyskać ważną sesję w nowym schemacie — pytanie, które pozostawia otwarte sama dokumentacja poprawki.

Co zalecają źródła rekordu

Każdą instalację w wersji 0.1.1-rc.2 lub wcześniejszej należy uznać za objętą problemem, niezależnie od sposobu pakowania, w tym kopię osadzoną w nakładce desktopowej.

• Zainstaluj wersję 0.1.2-alpha.2 lub nowszą z npm; najnowszą wersją w rejestrze w dniu 27 października 2026 r. była wersja 0.2.2-alpha.2.

• Jeśli nie możesz przeprowadzić aktualizacji, zatrzymaj interfejs webowy, gdy nie jest używany, i usuń wszelkie tunele, serwery proxy lub przekierowania portów prowadzące do portu 3080.

• Sprawdź, czy port 3080 jest osiągalny z dowolnego miejsca innego niż loopback, z uwzględnieniem przekierowywania portów kontenerów, odwrotnych proxy i tuneli SSH.

• Rejestruj zmiany eskalacji uprawnień i trybu zatwierdzania na poziomie harnessu, ponieważ atak zadziałał dzięki temu, że nieautoryzowana eskalacja wyglądała jak rutynowa czynność.

Wszystkie pięć pochodzi z notatki Cloud Security Alliance oraz relacji The Hacker News; sam rekord CVE nie zawiera żadnych wskazówek dotyczących usunięcia problemu poza informacją o poprawionej wersji.

Dlaczego Cloud Security Alliance interpretuje to jako wzorzec

Notatka Cloud Security Alliance umieszcza tę CVE obok dwóch innych udokumentowanych przez siebie w 2026 r. niepowodzeń w izolowaniu agentów kodujących: GuardFall z 1 lipca, w którym dziesięć z jedenastu popularnych otwartoźródłowych agentów kodujących można było skłonić do uruchamiania poleceń powłoki, których ich zabezpieczenia miały blokować, oraz ustaleń z 22 lipca dotyczących przekazania zaufania, zgodnie z którymi ograniczony agent zapisał plik, a później wykonał go zaufany komponent poza piaskownicą. W notatce wyraźnie zaznaczono, że wszystkie trzy przypadki pochodzą z jej własnych badań, a nie z wyczerpującego przeglądu rynku, oraz że nie ustalono, czy wzorzec ten uogólnia się poza zbadanymi przez nią agentami. Twierdzi ona natomiast, że niepowodzenia te występują na różnych warstwach — zabezpieczeń poleceń, zaufania w dalszej części łańcucha i obecnie uwierzytelniania płaszczyzny sterowania — i dlatego zaleca traktowanie architektury piaskownicy jako kwestii zakupowej, a nie spełnionego wymogu.

Własna dokumentacja bezpieczeństwa DeepSeek nie przeczy temu odczytowi. Plik SAFETY.md w repozytorium stwierdza, że oprogramowanie „nie przeszło audytu bezpieczeństwa i nie można go traktować jako bezpiecznego ani gotowego do produkcji” oraz że stosowanie piaskownicy, prośby o zatwierdzenie i mechanizmy kontroli uprawnień „nie gwarantują izolacji ani nie zapobiegają szkodom”. Luka w uwierzytelnianiu, która pozwalała agentowi wydostać się przez API sterowania, została zamknięta w bieżących kompilacjach. Asymetria, która sprawiła, że ta ucieczka była krótka — granica wokół operacji zapisu i brak jakiejkolwiek granicy wokół sieci — pozostaje deklarowanym ograniczeniem piaskownicy, a nie defektem, który poprawka miała naprawić.