Co osiągnęła jedna wiadomość

23 lipca firma bezpieczeństwa Accomplish ujawniła lukę, którą nazwała SharedRoot. Jej główny badacz, Oren Yomtov, opisał test rzeczowo: podłączyli folder do nowej sesji Claude Cowork, wysłali krótką wiadomość i patrzyli, jak agent opuszcza piaskownicę.

Claude Cowork uruchamia swojego agenta wewnątrz wirtualnej maszyny Linux na Macu, zbudowanej na własnej platformie wirtualizacji Apple. Każda sesja otrzymuje użytkownika bez uprawnień i filtrowanie wywołań systemowych, co nadaje słowu piaskownica ciężar. Problemem nie była skrzynka. Problemem było to, co skrzynka mogła zobaczyć.

Cały system plików gospodarza był zamontowany w tej maszynie z dostępem do odczytu i zapisu. Od wewnątrz agent sięgnął kluczy SSH, danych chmurowych, kluczy API, repozytoriów kodu i wszystkiego innego, czego mogło dotknąć zalogowane konto. Według wyliczeń firmy około 500.000 osób uruchomiło Cowork lokalnie, zanim ekspozycja została usunięta.

Dlaczego nie pojawiła się łatka

Anthropic otrzymał zgłoszenie i zamknął je jako informacyjne. W języku programów nagród za błędy jest to potwierdzenie bez dedykowanej łatki, a firma umieściła je w oknie trzydziestu dni, które jej program rezerwuje na takie przypadki.

Odpowiedź była architektoniczna, a nie naprawcza. Obecna wersja Cowork uruchamia agenta domyślnie w chmurze Anthropic, a badacze zgadzają się, że ta lokalna ścieżka ucieczki nie wydaje się tam obowiązywać. Ustawienie domyślne odsunęło ryzyko od maszyny klienta, dla każdego, kto je zaakceptuje.

Pozostaje więc wyraźna linia pośrodku. Jeśli Twoi programiści używają agenta w domyślnym trybie chmurowym, ta ucieczka nie jest ich problemem. Jeśli wybierają uruchomienie lokalne, dla prywatności, do pracy offline lub z przyzwyczajenia, biorą na siebie całą ekspozycję, a żadna aktualizacja jej za nich nie usunie.

Granica była montażem, a nie murem

Pouczający szczegół to, jak zwyczajna była ta słabość. System plików gospodarza był współdzielony z maszyną wirtualną tak, by widział go tylko użytkownik root w gościu. Ucieczka po prostu stała się rootem wewnątrz gościa, przez znaną lukę w jądrze Linux oznaczoną jako CVE-2026-46331, a montaż zrobił resztę.

Lekcja dla obrońców to nie błąd jednego dostawcy, lecz jego kształt. Piaskownica, która współdzieli całego gospodarza, jest tak silna, jak założenie, że nic w środku nigdy nie zostanie rootem. Przy agencie, który czyta niezweryfikowaną treść i na jej podstawie działa, jest to właśnie założenie, którego nie powinieneś czynić.

Co zabezpieczyć przed uruchomieniem lokalnym

Traktuj każdą maszynę uruchamiającą lokalnego agenta tak, jakby agent mógł odczytać folder domowy, bo w tym przypadku mógł. Trzymaj klucze SSH i dane chmurowe z dala od laptopów deweloperskich, które uruchamiają agentów z niezweryfikowaną treścią, albo ogranicz tych agentów tak, by współdzielenie systemu plików gospodarza było zawężone do podłączonych folderów i zamontowane tylko do odczytu.

Tam, gdzie platforma na to pozwala, badacze zalecają wyłączenie przestrzeni nazw użytkownika bez uprawnień, zaostrzenie filtra wywołań systemowych i uniemożliwienie ładowania na żądanie nieużywanych modułów jądra - kroki, które zablokowałyby właśnie ten łańcuch. To kontrole konfiguracyjne, a więc należą do Ciebie, nie do dostawcy.

Obowiązek zgłoszenia również należy do Ciebie. Na mocy NIS2 w Unii Europejskiej i DORA dla firm finansowych wyciek danych programisty, który dociera do produkcji, jest Twoim incydentem, zgłaszanym w terminie - w Polsce do CSIRT NASK. Piaskownicę sprzedano jako bezpieczeństwo; odpowiedzialność zawsze była Twoja.

Czytaj dalej: Otwartymi drzwiami było repozytorium pakietów  |  SI sama przeprowadziła cały atak ransomware