CVE-2026-82217 w Eclipse Theia: agent AI mógł zapisywać pliki poza workspace

Opublikowane dziś CVE-2026-82217 pokazuje, jak błąd w pozornie prostym narzędziu plikowym może zmienić prompt injection w naruszenie hosta. W Eclipse Theia od wersji 1.73.0 do wydań wcześniejszych niż 1.75.0 narzędzia zmiany plików używane przez AI Agent Mode rozwiązywały ścieżkę podaną przez model bez sprawdzenia, czy wynik nadal znajduje się w bieżącym workspace. Model mógł przez to zapisać albo usunąć plik poza projektem z uprawnieniami użytkownika systemowego backendu Theia.

Rekord otrzymał CVSS 3.1: 8,8 (High) i klasyfikację CWE-22, czyli niewłaściwe ograniczenie ścieżki do chronionego katalogu. Wersją naprawczą jest Eclipse Theia 1.75.0. Źródła wskazują writeFileContent, suggestFileContent oraz pomocnicze funkcje odpowiedzialne za replacement i stan zmian. Luka jest szczególnie istotna w Agent Mode, bo zapis może zostać zastosowany bez osobnego okna potwierdzenia.

Nie jest to twierdzenie, że każde polecenie w Theia natychmiast wykonuje kod. Istnieje jednak jasny łańcuch: niezaufana treść wpływa na model, model wybiera ścieżkę, backend wykonuje operację poza workspace, a zmodyfikowany plik może zostać później uruchomiony przez powłokę, SSH, narzędzie budujące lub samą aplikację.

Gdzie kończyła się oczekiwana granica

Użytkownik otwierający repozytorium zwykle zakłada, że agent z uprawnieniem edycji może zmieniać właśnie to repozytorium. To nie tylko wygodny model mentalny. Workspace jest granicą, na podstawie której zespół może oceniać diff, przeglądać historię, odtworzyć pliki i ograniczyć zakres działania automatyzacji.

W podatnych wersjach ścieżka wygenerowana przez model trafiała do resolvera, ale wynik nie przechodził wiarygodnej kontroli zawierania. Sekwencja z .. mogła wyjść do katalogu nadrzędnego. Ścieżka absolutna omijała punkt startowy, a wariant rozwijający ~ mógł wskazać katalog domowy konta uruchamiającego backend. Ten sam problem dotyczył nie tylko tworzenia pliku, lecz również helperów obsługujących propozycje, podmiany i stan zmian.

Bezpieczna walidacja nie może polegać na wyszukaniu napisu ... Najpierw trzeba znormalizować i rozwiązać ścieżkę, uwzględnić składnię systemu operacyjnego, linki symboliczne oraz różnice wielkości liter, a dopiero później porównać wynik z kanonicznym katalogiem bazowym. Ważne jest też zachowanie w momencie użycia: sprawdzenie wykonane przed zmianą linku symbolicznego może zostać unieważnione przez wyścig czasowy.

Dlaczego model zwiększa osiągalność błędu

W klasycznym edytorze argument funkcji zapisu pochodzi z działania użytkownika lub kodu rozszerzenia. W narzędziu agenta argument generuje model na podstawie całego kontekstu: wiadomości użytkownika, plików repozytorium, wyników wyszukiwania, dokumentacji, logów i treści pobranych z zewnątrz. Część tego kontekstu jest niezaufana.

Atakujący nie musi więc przekonać operatora, by ręcznie wpisał ścieżkę poza projektem. Może umieścić instrukcję w README zależności, issue, komentarzu kodu, pliku danych albo treści strony analizowanej przez agenta. Jest to pośrednie prompt injection: człowiek prosi o legalne zadanie, ale materiał roboczy zawiera instrukcję próbującą przejąć decyzje modelu.

Sam prompt injection nie daje magicznych uprawnień. Wykorzystuje uprawnienia narzędzi już przydzielonych agentowi. W tym przypadku nieprawidłowa granica ścieżki sprawiała, że deklarowane „edytowanie workspace” w praktyce znaczyło „operacje plikowe dostępne dla konta backendu”. To różnica między błędem jakości odpowiedzi a podatnością bezpieczeństwa.

Od zapisu pliku do wykonania kodu

Zapis poza workspace może bezpośrednio naruszyć poufność lub integralność, ale najbardziej ryzykowne są pliki konsumowane później jako instrukcje. Rekord CVE wskazuje pliki startowe powłoki oraz ~/.ssh/authorized_keys. Podobną analizę trzeba przeprowadzić dla konfiguracji menedżera pakietów, hooków kontroli wersji, zadań uruchamianych przez IDE, unitów użytkownika, skryptów CI montowanych z hosta i katalogów obserwowanych przez usługę.

To nie znaczy, że każda taka ścieżka jest dostępna w każdym wdrożeniu. Kontener może mieć tylko odczyt, backend może działać jako użytkownik bez katalogu domowego, a SSH może być nieobecne. Z drugiej strony środowisko developerskie zwykle ma szeroki dostęp do kodu, poświadczeń repozytoriów, kluczy do rejestru pakietów i socketów narzędziowych. Dlatego wynik 8,8 jest spójny z potencjalnym wpływem, mimo że do wejścia na ścieżkę potrzebne jest sterowanie wynikiem modelu.

Usunięcie pliku również ma znaczenie. Agent może uszkodzić konfigurację, źródła spoza bieżącego projektu albo dane wspólne dla kilku workspace’ów. Snapshot repozytorium nie pomoże, jeśli cel nie był częścią repozytorium.

Kogo dotyczy CVE-2026-82217

Zagrożone są produkty i środowiska zbudowane na Eclipse Theia 1.73.x lub 1.74.x, które udostępniają AI Agent Mode z narzędziami zmiany plików. Sama obecność pakietu Theia w zależnościach nie rozstrzyga osiągalności. Trzeba odpowiedzieć na cztery pytania:

jaka wersja znajduje się w faktycznie uruchomionym obrazie lub aplikacji;
czy Agent Mode i wskazane narzędzia są dostępne dla użytkownika;
z jakimi uprawnieniami, katalogiem domowym i mountami działa backend;
czy agent analizuje niezaufane repozytoria lub zewnętrzne treści.

W rozwiązaniach white-label wersja produktu może różnić się od wersji bazowych pakietów Theia. Weryfikuj lockfile, SBOM i zawartość obrazu. Desktop, zdalny workspace i przeglądarkowy frontend z backendem na serwerze mają odmienny obszar wpływu: operacja zawsze działa tam, gdzie uruchomiony jest komponent wykonujący narzędzie plikowe.

Priorytet: aktualizacja i ograniczenie procesu

Podstawową naprawą jest aktualizacja do Eclipse Theia 1.75.0 lub późniejszego kompatybilnego wydania i przebudowanie produktu wykorzystującego jej komponenty. Jeżeli szybki rollout jest niemożliwy, wyłącz Agent Mode lub odbierz mu narzędzia zapisujące, proponujące i usuwające pliki. Sam komunikat w system prompt, że agent „nie powinien opuszczać workspace”, nie stanowi zabezpieczenia.

Warstwa systemowa powinna ograniczać konsekwencje kolejnego błędu. Uruchamiaj backend jako oddzielnego użytkownika bez uprawnień administracyjnych. Montuj tylko potrzebne katalogi; sekrety udostępniaj chwilowo i w minimalnym zakresie. Rozważ read-only dla katalogu domowego oraz izolowany, efemeryczny workspace. Nie montuj do środowiska agenta socketu Dockera ani szerokich poświadczeń chmurowych bez uzasadnienia.

Ważna jest także kontrola zdolności. Narzędzie powinno otrzymywać uchwyt do workspace lub identyfikator zasobu, nie dowolny systemowy pathname. Backend, a nie model i nie frontend, musi wymuszać kanoniczną granicę. Operacje wysokiego ryzyka powinny wymagać zatwierdzenia pokazującego pełną, znormalizowaną ścieżkę i różnicę zmian.

Jak bezpiecznie zweryfikować poprawkę

Test regresji nie wymaga dotykania prawdziwego katalogu domowego. Utwórz izolowany katalog tymczasowy zawierający workspace i sąsiadujący plik-wabik. Następnie sprawdź mały zestaw ścieżek: zwykły plik w projekcie powinien działać, a ścieżka względna wychodząca wyżej, absolutna, wariant katalogu domowego oraz przejście przez link symboliczny powinny zostać odrzucone przed zapisem i usunięciem.

Testuj wszystkie funkcje wymienione w advisory, nie tylko writeFileContent. Wiele regresji bierze się z naprawienia jednego entry pointu przy pozostawieniu wspólnego helpera lub drugiej ścieżki bez kontroli. Na Windows uwzględnij litery dysków, UNC, separatory i normalizację wielkości liter; na systemach POSIX — symlinki i mounty.

Po aktualizacji sprawdź, czy błąd jest bezpieczny: użytkownik powinien dostać jasną informację o naruszeniu granicy, ale odpowiedź nie powinna ujawniać niepotrzebnej struktury hosta. Zapis odmowy powinien zawierać identyfikator sesji, narzędzie i znormalizowany cel w telemetryce dostępnej dla zespołu bezpieczeństwa.

Polowanie na ślady nadużycia

W logach narzędzi szukaj ścieżek zawierających katalog nadrzędny, katalog domowy, litery dysków lub cele spoza katalogu projektu. Porównaj czas operacji z promptami, źródłami kontekstu i identyfikatorem modelu. Szczególnie ważne są modyfikacje plików startowych, kluczy SSH, konfiguracji powłoki, ustawień menedżerów pakietów oraz plików wykonywanych automatycznie.

Jeżeli telemetryka agenta nie przechowuje docelowych ścieżek, sięgnij po auditd, EDR, dzienniki systemu plików, historię powłoki i metadane snapshotów. Sprawdź także utworzone procesy i połączenia wychodzące po modyfikacji. W środowisku efemerycznym przeanalizuj bazowy host i system sekretów, a nie tylko zniszczony kontener.

Brak podejrzanego wpisu w repozytorium nie wyklucza problemu — istotą CVE jest właśnie zapis poza zakresem obserwowanym przez Git. Jeśli istnieje wiarygodne podejrzenie modyfikacji pliku wykonywalnego lub konfiguracyjnego, odtwórz środowisko z zaufanego obrazu i obróć poświadczenia dostępne backendowi.

Fakty źródłowe i wnioski Breachroad

Zakres 1.73.0–<1.75.0, lista klas narzędzi, brak kontroli zawierania i potencjalna eskalacja przez pliki wykonywane przez host pochodzą z rekordu CVE przygotowanego przez Eclipse Foundation. Model zagrożeń dla wdrożeń, zalecane mounty, telemetria i plan regresji są wnioskami Breachroad. Źródła nie informują o potwierdzonej eksploatacji w środowiskach produkcyjnych.

Źródła pierwotne

Granica workspace musi być egzekwowana przez kod, a nie przez instrukcję dla modelu. Na warsztatach z bezpiecznych wdrożeń AI zespoły uczą się projektować uprawnienia agentów, zgody i izolację środowiska. Dla produktów z narzędziami o wysokim wpływie kontrolowany AI red teaming pozwala zweryfikować, czy niezaufany kontekst może przejąć realne operacje.