Luka w Docker Sandboxes. Agent AI mógł sięgać poza sandbox

Czym jest Docker Sandboxes

Docker Sandboxes to narzędzie wiersza poleceń sbx, które uruchamia agentów AI do programowania, takich jak Claude Code, Codex czy Gemini CLI, w osobnych środowiskach. Każdy sandbox działa w lekkiej maszynie wirtualnej z własnym jądrem systemu, systemem plików i siecią. Agent może tam instalować pakiety, budować obrazy i uruchamiać kontenery bez dostępu do reszty komputera.

Programista udostępnia agentowi tylko wybrane katalogi, zwykle folder projektu. Lista tych katalogów działa jak lista dozwolonych miejsc i według dokumentacji Dockera jest granicą tego, do czego sandbox ma dostęp. Takie rozwiązania zyskują popularność, bo firmy coraz częściej pozwalają agentom samodzielnie wykonywać polecenia.

Na czym polegała luka CVE-2026-103916

Problem dotyczył polecenia sbx cp, które kopiuje pliki między sandboxem a komputerem programisty. Według opisu w rejestrze CVE, przygotowanego przez Dockera, polecenie nie ograniczało ścieżek po stronie komputera do udostępnionego katalogu roboczego. Działało z pełnymi uprawnieniami użytkownika i nie sprawdzało listy dozwolonych katalogów.

Agent ma prawo zapisu w katalogu roboczym, więc mógł tam utworzyć dowiązanie symboliczne, czyli skrót wskazujący inne miejsce na dysku. Samo dowiązanie wewnątrz sandboxa nic nie dawało. Dopiero gdy użytkownik uruchomił kopiowanie, narzędzie podążało za skrótem i działało na plikach spoza sandboxa.

Peyton Kennedy z Endor Labs, który zgłosił lukę, opisał dwa skutki. Pierwszy to odczyt pliku z komputera do sandboxa, na przykład danych logowania do chmury albo klucza SSH. Drugi to nadpisanie pliku w katalogu domowym, co według badacza mogłoby prowadzić do uruchomienia kodu poza sandboxem. Badacz zaznacza, że tego drugiego scenariusza nie zademonstrował i przedstawia go jako wniosek, a nie wynik testu.

Kogo dotyczy i jak poważna jest luka

Luka dotyczy wyłącznie osób i firm, które używają Docker Sandboxes, czyli narzędzia sbx. Nie dotyczy zwykłego Dockera, Docker Desktop ani kontenerów uruchamianych bez sandboxów. Docker zaznacza w rejestrze CVE, że podatne są wersje od 0.28.0 do wersji poprzedzającej 0.51.0.

• Identyfikator - CVE-2026-103916, opublikowany przez Dockera 3 listopada 2026 roku.
• Podatne wersje - od 0.28.0 do 0.50.x, na macOS, Linuksie i Windowsie.
• Poprawka - wersja 0.51.0 wydana 3 listopada 2026 roku.
• Ocena Dockera - 8,4 pkt w CVSS 4.0, poziom wysoki.
• Ocena Endor Labs - 8,2 pkt w CVSS 3.1 i 7,3 pkt w CVSS 4.0.
• Warunek - użytkownik musi uruchomić kopiowanie plików poleceniem sbx cp.

Dlaczego warunek działania użytkownika niewiele chroni

Kopiowanie wyników, logów i zależności między sandboxem a komputerem to codzienna czynność w pracy z agentem. Endor Labs zwraca uwagę, że polecenie podatne na lukę ma dokładnie taką postać, jaką pokazuje pomoc narzędzia, a w pracy agentowej kopiowanie często proponuje sam agent.

Udane kopiowanie nie wyświetlało żadnego komunikatu ani pełnej ścieżki docelowej, więc człowiek nadzorujący pracę agenta nie miał czego zauważyć. Atakujący nie musi przy tym przejmować komputera. Wystarczy, że agent przeczyta złośliwe instrukcje ukryte w zależności, dokumentacji albo na stronie internetowej i wykona je jako część zadania.

Opóźniona poprawka i wcześniejsze błędy

Według Endor Labs Docker planował początkowo wydać poprawkę 13 października 2026 roku w wersji 0.48.0, ale naprawa okazała się trudniejsza. Wersja 0.50.0 z 26 października częściowo zaostrzyła zasady kopiowania, a pełna poprawka trafiła do wersji 0.51.0. W jej opisie Docker podaje, że sbx cp blokuje teraz dowiązania symboliczne, które próbują wyprowadzić kopiowanie poza zamontowane katalogi.

To nie pierwszy problem z tym poleceniem. Wcześniejsza luka CVE-2026-17106, naprawiona w wersji 0.38.0, pozwalała zapisać pliki poza katalogiem docelowym przez odpowiednio przygotowane ścieżki w archiwum. W naszej ocenie oba przypadki pokazują, że sandbox chroni tylko w takim zakresie, w jakim chronione są wszystkie kanały wymiany plików z komputerem, a nie tylko główny mechanizm izolacji.

Co zrobić teraz

Najważniejsza jest aktualizacja do wersji 0.51.0 lub nowszej. Przed aktualizacją warto przeczytać informacje o zmianach, bo wersja 0.51.0 zmienia sposób uruchamiania wbudowanych agentów. Sandboxy utworzone we wcześniejszych wersjach działają dalej, ale przed częścią operacji trzeba je odtworzyć, a przed usunięciem sandboxa należy zapisać pliki i wysłać niezatwierdzone zmiany do repozytorium.

1. Zaktualizuj narzędzie sbx do wersji 0.51.0 lub nowszej na wszystkich komputerach zespołu.
2. Do czasu aktualizacji nie kopiuj plików do ani z katalogów roboczych, które agent mógł zmienić, bez sprawdzenia, czy nie zawierają nieoczekiwanych dowiązań symbolicznych.
3. Ogranicz pliki z danymi logowania na komputerach, na których działają agenci, i stosuj krótko ważne tokeny.
4. Jeśli agent pracował na niezaufanych repozytoriach lub stronach, przejrzyj zmiany w plikach konfiguracyjnych katalogu domowego, na przykład w ustawieniach powłoki i Gita.
5. W firmie dopisz Docker Sandboxes do rejestru narzędzi, które wymagają szybkiego wdrażania poprawek bezpieczeństwa.

Znaczenie dla polskich zespołów

Polskie software house'y i działy IT coraz częściej dają agentom AI dostęp do repozytoriów i terminala, a sandbox ma ograniczać skutki błędu lub manipulacji. Ta luka pokazuje, że izolacja nie zwalnia z kontroli plików wymienianych z komputerem programisty, zwłaszcza tam, gdzie leżą klucze do chmury i repozytoriów klientów.

Docker nie podał, czy luka była wykorzystywana w praktyce. Nie ma też informacji o atakach na polskie firmy. Nie publikujemy szczegółów technicznych, które ułatwiałyby jej wykorzystanie, a pełny opis badacza jest dostępny w źródle.