GhostApproval – gdy AI pokazuje inny plik niż zapisuje

Wyobraź sobie sytuację: asystent programowania AI pyta cię „Czy chcesz edytować plik project_settings.json?”, klikasz Akceptuj, a on w tym momencie dopisuje klucz publiczny atakującego do twojego pliku ~/.ssh/authorized_keys. Brzmi jak science fiction? Niestety, to rzeczywistość. 8 lipca 2026 roku firma badawcza Wiz opublikowała wyniki testów, które pokazują, że sześć najpopularniejszych narzędzi AI do kodowania można w ten sposób oszukać. Atak, nazwany GhostApproval, wymaga tylko jednego – by programista sklonował spreparowane repozytorium i poprosił agenta o uruchomienie workspace’u. Reszta dzieje się automatycznie.

Mechanizm bazuje na starym jak Unix mechanizmie dowiązań symbolicznych (symlink). Plik o niewinnej nazwie, np. settings.json, w rzeczywistości wskazuje na zupełnie inny plik w systemie – na przykład na authorized_keys lub .zshrc. Asystent AI wykonuje polecenie „dodaj linię do pliku konfiguracyjnego” i podąża za dowiązaniem, zapisując dane w miejscu, które programista chciałby trzymać z daleka od złośliwych treści. Wiz potwierdziło, że dotyczy to Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity oraz Windsurf. Łącznie narzędzia te obsługują znaczną część społeczności deweloperów korzystających z AI-assisted coding.

Jak GhostApproval przejmuje twoją maszynę

Atak nie wymaga egzotycznych exploitów. Wykorzystuje podstawową własność systemów plików: dowiązanie symboliczne (symlink) to taki plik, który nie zawiera danych, a jedynie ścieżkę do innego pliku. Kiedy aplikacja zapisuje do symlinka, system operacyjny automatycznie przekierowuje zapis do rzeczywistego celu. W GhostApproval atakujący umieszcza w repozytorium plik o nazwie np. project_settings.json, który tak naprawdę jest dowiązaniem do ~/.ssh/authorized_keys – pliku decydującego o tym, kto może zalogować się na twoją maszynę przez SSH bez hasła. README repozytorium lub plik konfiguracyjny agenta zawiera instrukcję: „dodaj linię do tego pliku w ramach inicjalizacji workspace’u”. Asystent AI postępuje zgodnie z instrukcją, system podąża za dowiązaniem, a klucz SSH ląduje tam, gdzie chce intruz. Jeśli twój komputer jest osiągalny przez SSH, atakujący uzyskuje trwały zdalny dostęp – bez twojej wiedzy.

Drugi wariant: trwałe wykonanie kodu bez SSH

Wiz odkryło też wariant, w którym docelowym plikiem jest ~/.zshrc – plik startowy powłoki. Ponieważ shell wykonuje go przy każdym otwarciu terminala, atakujący osiąga trwałe wykonanie kodu (persistent code execution) nawet bez dostępu SSH. W tym przypadku wystarczy, że ofiara otworzy nowe okno terminala, a złośliwe polecenie zostanie wykonane.

Dlaczego „człowiek w pętli” nie chroni

Najbardziej niepokojącą konkluzją z raportu Wiz nie jest fakt, że agenci AI podążają za dowiązaniami symbolicznymi – to znany problem od dekad. Kluczowe jest to, gdzie następuje oszustwo: w oknie zatwierdzania, które miało być właśnie mechanizmem bezpieczeństwa. Kiedy agent zamierza zapisać plik, większość narzędzi pokazuje okno dialogowe z nazwą pliku do edycji. W GhostApproval to okno wyświetla nazwę symlinka – niewinne project_settings.json – a nie rzeczywisty cel zapisu. Programista widzi rutynową edycję konfiguracji i klika Akceptuj. Tymczasem zapis trafia do .ssh/authorized_keys.

„Model bezpieczeństwa 'człowiek w pętli’ działa tylko wtedy, gdy pętla dostarcza dokładne informacje. Gdy agent pokazuje jedno, a robi drugie, zatwierdzenie użytkownika traci znaczenie. Okno potwierdzenia zmienia się z mechanizmu bezpieczeństwa w formalność.” – Maor Dokhanian, badacz Wiz

Szczególnie wymowny jest przypadek Claude Code. Podczas testów Wiz, wewnętrzny łańcuch rozumowania agenta poprawnie zidentyfikował, że project_settings.json jest „w rzeczywistości plikiem konfiguracyjnym zsh”. Ta trafna informacja nigdy jednak nie trafiła do okna dialogowego. Agent wiedział prawdę, ale deweloperowi pokazano coś innego. To strukturalna luka: warstwa wyświetlania zatwierdzenia i wewnętrzne rozumowanie agenta są od siebie odseparowane. Jedna poprawnie rozpoznaje dowiązanie, druga nie. Użytkownik zgadza się na edycję pliku, którego nigdy nie widział.

Niektóre narzędzia są jeszcze gorzej zabezpieczone. Wiz odkryło, że Windsurf zapisuje klucz SSH na dysk jeszcze przed pojawieniem się okna aprobaty. Przyciski Akceptuj i Odrzuć są w tym momencie jedynie mechanizmem cofania (undo), a nie bramką. Augment z kolei nie pokazuje żadnego okna dialogowego, a badacze wykazali, że potrafi on w ciszy odczytać plik z danymi uwierzytelniającymi AWS znajdujący się poza katalogiem projektu.

Reakcje producentów: trzech załatało, dwóch milczy, jeden dyskutuje

Wiz zgłosiło swoje ustalenia producentom w lutym 2026 roku, a proces ujawnienia trwał ponad 90 dni. Odpowiedzi są mocno zróżnicowane. Amazon Q Developer naprawił lukę w wersji Language Server 1.69.0 (CVE-2026-12958) wdrożonej 27 maja. AWS informuje, że aktualizacja instaluje się automatycznie dla większości użytkowników; ci korzystający z sieci blokujących automatyczne aktualizacje muszą przeładować IDE lub zainstalować plugin ręcznie. Dodatkowo Amazon Q posiadał osobną, załataną podatność (CVE-2026-12957), w której złośliwe repozytorium mogło automatycznie załadować plik konfiguracyjny i ukraść dane AWS bez użycia dowiązań symbolicznych.

Cursor wydał łatkę w wersji 3.0 (CVE-2026-50549) 5 czerwca 2026 roku. Firma doceniła zarówno Wiz, jak i Cato AI Labs, których wcześniejsze badania (pod nazwą DuneSlide) zidentyfikowały pokrywającą się lukę w sandboxie Cursora. Google załatało Antigravity w wersji 1.19.6, wdrożonej 22 maja 2026 roku; przypisanie CVE jest w toku.

Zupełnie inaczej wygląda sytuacja z Augment i Windsurf. Obie firmy potwierdziły otrzymanie raportu (Windsurf odpowiedział 23 czerwca), ale do 10 lipca nie wydały łat ani nie podały terminu ich publikacji.

Stanowisko Anthropica: czy to w ogóle luka?

Anthropic zajął wyjątkowe stanowisko – uznał, że scenariusz GhostApproval leży „poza naszym obecnym modelem zagrożeń”. Firma argumentuje, że programista, który ufa repozytorium i zatwierdza edycję pliku, podjął obie decyzje samodzielnie; narzędzie po prostu spełniło jego wolę. Dodatkowo Anthropic przypomina, że Claude Code w wersji 2.1.32 (z 5 lutego 2026) zawierał już ostrzeżenie o dowiązaniach symbolicznych – dodane w ramach proaktywnego wzmacniania bezpieczeństwa, dziewięć dni przed zgłoszeniem Wiz. Firma wyjaśnia, że wcześniejszy brak odpowiedzi na raport wynikał z automatycznego triażu, a nie celowego zaniechania.

Ten spór rodzi fundamentalne pytanie projektowe, wykraczające poza pojedynczego dostawcę: jeśli programista wyraźnie ufa repozytorium, a następnie wyraźnie zatwierdza to, co narzędzie przedstawia jako rutynową edycję konfiguracji, czy narzędzie spełniło swoją rolę? Kontrargument – wsparty kategorią słabości MITRE CWE-451 („Błędna reprezentacja krytycznych informacji w interfejsie użytkownika”) – mówi, że zatwierdzenie „project_settings.json” to nie to samo, co zatwierdzenie „~/.ssh/authorized_keys”. Żaden rozsądny programista nie uzna tych dwóch rzeczy za tożsame. Asymetria informacji między tym, co wie agent, a tym, co mówi użytkownikowi, jest – w tym ujęciu – samą podatnością, niezależnie od liczby formalnych kroków zatwierdzenia.

Ataki w praktyce: robak Miasma już działa

GhostApproval samo w sobie nie zostało zaobserwowane w rzeczywistych atakach – to dotąd badanie akademickie. Jednak technika wykorzystywania plików konfiguracyjnych agentów AI do atakowania programistów nie jest teoretyczna. 5 czerwca 2026 roku robak Miasma, powiązany z grupą TeamPCP, dotarł do organizacji Microsoft Azure na GitHubie. Wcześniej skompromitowany autor wrzucił złośliwy commit do repozytorium Azure/durabletask. Commit nie zmieniał kodu źródłowego – zawierał pięć plików konfiguracyjnych dla Claude Code, Gemini CLI, Cursor i VS Code, każdy skonfigurowany tak, by uruchomić 4,6-megabajtowy ładunek kradnący dane uwierzytelniające zaraz po otwarciu repozytorium w którymkolwiek z tych narzędzi.

GitHub automatycznie wyłączył 73 repozytoria w czterech organizacjach Microsoftu w ciągu 105 sekund. Ładunek Miasma polował na klucze AWS, Azure, GCP, tokeny GitHub, sekrety Kubernetes, dane z 1Password, gopass i ponad 90 innych narzędzi deweloperskich. Żadna z tych podatności nie ma przypisanego CVE, a standardowe skanery nie wykrywają ich, ponieważ nie wymagają instalacji pakietów – pliki konfiguracyjne są odczytywane bezpośrednio.

Co możesz zrobić już dziś – praktyczne kroki

Najważniejsze: sprawdź wersję swojego narzędzia. Dla Amazon Q Developer – Language Server 1.69.0 lub nowszy; przeładowanie IDE powinno uruchomić aktualizację, chyba że sieć blokuje automatyczne pobieranie. Dla Cursor – wersja 3.0 lub nowsza. Dla Google Antigravity – wersja 1.19.6 lub nowsza.

Jeśli używasz Augment lub Windsurf – na razie nie ma łatki. Zalecenie ekspertów Wiz: nie uruchamiaj agentów AI na repozytoriach z niepewnych źródeł, dopóki nie pojawi się poprawka. Ta rada dotyczy zresztą wszystkich narzędzi – nawet załatana wersja może być narażona, jeśli atakujący znajdzie nowy sposób na ominięcie okna aprobaty.

Dodatkowe środki ostrożności zmniejszają ryzyko niezależnie od używanego narzędzia:

Uruchamiaj agentów AI w kontenerze lub sandboxie z ograniczonym dostępem do systemu plików – wtedy dowiązanie do .ssh/authorized_keys trafi donikąd.
Przed każdą sesją przeglądaj plik README i pliki konfiguracyjne agenta (np. .claude/settings.json). Szukaj instrukcji modyfikowania plików lub uruchamiania poleceń.
Po sesji w nieznanym repozytorium sprawdź znaczniki czasowe plików poza katalogiem projektu – np. poleceniem ls -la ~/.ssh/authorized_keys ~/.zshrc. Jeśli któryś zmienił się podczas pracy agenta (a nie był modyfikowany przez ciebie), to czerwona flaga.
W przypadku kompromitacji – natychmiast obróć wszystkie klucze SSH i odwołaj zdalny dostęp. Jeśli otwierałeś repozytoria Microsoft Azure na GitHubie między 2 a 5 czerwca 2026 roku, obróć wszystkie dane w chmurze – robak Miasma mógł być aktywny.

Rozwiązanie musi leżeć po stronie wyświetlania

Warunkiem koniecznym jest, by przed każdym zapisem pliku agent wywołał funkcję typu POSIX realpath(), która rozpoznaje dowiązania symboliczne i zwraca rzeczywistą ścieżkę. Ta ścieżka – .ssh/authorized_keys, .zshrc, cokolwiek innego – musi trafić do okna dialogowego. Jeśli rzeczywisty cel leży poza katalogiem projektu, okno musi to w widoczny sposób sygnalizować – zapis do pliku systemowego nie może wyglądać jak edycja lokalnej konfiguracji.

W przypadku Windsurf i Amazon Q – gdzie zapis występuje przed wyświetleniem okna – niezbędna jest zmiana kolejności: zapis może nastąpić dopiero po wyraźnej zgodzie użytkownika. Okno pojawiające się po fakcie to nie autoryzacja, a jedynie rejestr zdarzeń.

Te wymagania nie są nowatorskie. Przeglądarki internetowe od początku lat 2000. muszą wyświetlać prawdziwą domenę w pasku adresu, a nie spreparowany URL. Powód? To ta sama kategoria słabości: CWE-451 – błędna reprezentacja krytycznych informacji. Środek zaradczy jest ten sam od dwóch dekad: pokaż użytkownikowi prawdę. Teraz trzeba go zastosować do okien aprobaty w asystentach AI.

„Sześciu różnych dostawców niezależnie doszło do bardzo podobnego modelu zaufania. To sugeruje, że mamy do czynienia z wyzwaniem projektowym na skalę całej kategorii, a nie zbiorem izolowanych błędów implementacyjnych.” – Justin Greis, CEO Acceligence

GhostApproval to nie tylko pojedyncza luka – to symptom głębszego problemu. Gdy narzędzia AI zaczynają działać z uprawnieniami dewelopera, a ich interfejs użytkownika jest odłączony od wewnętrznego rozumowania, każda decyzja – nawet ta poprzedzona kliknięciem „Akceptuj” – może być podjęta na podstawie fałszywych informacji. Dopóki warstwa wyświetlania nie będzie wiernie odzwierciedlać rzeczywistych działań agenta, bezpieczeństwo pozostanie iluzją.