Plugin4Shell: Cztery agenty AI do kodowania zaufały pinowi, którego nigdy nie sprawdziły

17 września 2026 r. AIR Security, startup tworzący narzędzia bezpieczeństwa dla korporacyjnych agentów AI, opublikował badanie opisujące Plugin4Shell — bezklikową lukę umożliwiającą zdalne wykonanie kodu w czterech agentach do kodowania AI: Claude Code firmy Anthropic, Codex firmy OpenAI, GitHub Copilot i Gemini CLI firmy Google. Błąd nie tkwi w żadnym modelu. Znajduje się w operacji git checkout, którą każdy agent wykonuje podczas instalacji wtyczki, oraz w tym, że żaden z tych czterech nie zweryfikował, czy otrzymany kod jest kodem, który został przypięty. Dwa z czterech miały poprawkę w momencie upublicznienia badania. Dwa nie miały. Ten incydent to jeden z wpisów w Archiwum Incydentów AI Orca, które klasyfikuje go jako lukę w łańcuchu dostaw o wysokim stopniu ważności, bez zgłoszonych przypadków wykorzystania.

Co agenci tak naprawdę zrobili źle

Każdy objęty problemem agent instaluje wtyczki z marketplace, a każdy marketplace przypina wtyczkę do konkretnego commita git — 40-znakowego SHA — po przejrzeniu wtyczki. To przypięcie stanowi cały model bezpieczeństwa: recenzent zatwierdza jedną niezmienną wersję, a agent powinien nadal uruchamiać tę wersję, nawet jeśli repozytorium za nią później się zmieni. AIR opisuje tę lukę jako obejście przypinania SHA wtyczki. Agent wyewidencjonowuje dokładnie ten commit, który przypiął marketplace, ale nigdy nie weryfikuje, czy drzewo robocze, które w efekcie otrzymuje, jest tym commitem. Jak ujmują to badacze, agent „wyewidencjonowuje dokładnie ten commit, który przypiął marketplace, ale nigdy nie weryfikuje, czy faktycznie wylądował w tym miejscu, więc atakujący kontrolujący repozytorium wtyczki sprawia, że checkout prowadzi do złośliwego kodu, podczas gdy przypięcie nadal wygląda na respektowane”.

Git wypełnia tę lukę. Gdy nazwa jest jednocześnie prawidłową gałęzią i obiektem commita, git preferuje gałąź i jedynie wypisuje ostrzeżenie o niejednoznaczności. Atakujący, który kontroluje repozytorium pluginu, tworzy gałąź, której nazwa jest dokładnie przypiętym SHA w postaci 40 znaków szesnastkowych, wskazuje ją na złośliwy kod i czyni ją domyślną gałęzią repozytorium. Zwykłe klonowanie pobiera wtedy tę gałąź lokalnie pod nazwą o kształcie SHA, a późniejszy checkout wskazuje na nią. Sam przypięty commit może pozostać nietknięty, więc nic w przeglądanej wersji nie wygląda źle. Według AIR muszą zachodzić dwa warunki: gałąź nazwana SHA musi być gałęzią domyślną, ponieważ gałąź niedomyślna jest pobierana tylko jako zdalna referencja śledząca i checkout wróciłby do prawdziwego commita; oraz host git musi akceptować 40-znakową szesnastkową nazwę gałęzi. GitHub odrzuca takie nazwy od razu. Bitbucket i samodzielnie hostowane serwery git tego nie robią.

Gemini CLI zawiódł w inny sposób. Pobrał przypięty commit, zapisał go w pliku FETCH_HEAD repozytorium, a następnie wykonał checkout FETCH_HEAD — checkout, który nie musi odczytywać tego pliku. Repozytorium, którego domyślna gałąź sama nazywa się FETCH_HEAD, przekierowuje checkout do treści kontrolowanych przez atakującego i po cichu odrzuca pobrany commit. Opis tego mechanizmu w Cybersecurity News jest zgodny z opisem AIR, łącznie z rozróżnieniem obu wariantów.

Dlaczego nikt nie musiał nic klikać

Ten sam checkout uruchamia się ponownie podczas automatycznej aktualizacji wtyczek w tle, która jest domyślnie włączona w Claude Code i Codex. To właśnie sprawia, że atak jest zero-click, a nie tylko cichy: gdy marketplace podnosi przypięty SHA do rutynowej nowej wersji, każdy agent, który ma już zainstalowaną wtyczkę, ponownie uruchamia checkout bez monitu i bez działania użytkownika. Teza AIR jest taka, że ofiara nie musi niczego instalować nieuważnie. Wystarczy, że zainstalowała jedną wtyczkę z zaufanego marketplace, która została sprawdzona i przypięta dokładnie tak, jak przewiduje projekt.

Istnieją dwa sposoby, aby osiągnąć tę pozycję, i żaden z nich nie wymaga kontrolowania marketplace’u. W pierwszym atakujący publikuje naprawdę nieszkodliwą wtyczkę, która przechodzi weryfikację, buduje bazę instalacji, wysyła zwykłą aktualizację, a dopiero potem tworzy złośliwie nazwaną gałąź. W drugim atakujący przejmuje repozytorium stojące za wtyczką napisaną przez kogoś innego, której marketplace już ufa, a następnie wypycha złośliwą wersję do wszystkich, którzy mają ją zainstalowaną.

Liczby stojące za tymi dwiema ścieżkami pochodzą z wcześniejszych prac AIR, a nie z Plugin4Shell. W kampanii, którą firma nazywa The Story of Skills, twierdzi, że zbudowana przez nią wtyczka rozprzestrzeniła się na ponad 26 000 agentów, zanim została wycofana. W SkillJacking poinformowała, że 925 umiejętności już aktywnie używanych zostało przejętych od ich pierwotnych opiekunów, docierając do 134 000 agentów. Nagłówek AIR do wpisu o Plugin4Shell głosi, że „dotknięte zostały miliony agentów”; badanie nie podaje liczby narażonych instalacji, a żadna strona trzecia nie opublikowała takiej liczby.

Oś czasu i gdzie trafiły poprawki

AIR twierdzi, że w maju 2026 r. znalazł lukę, dysponując działającymi eksploitami proof-of-concept przeciwko wszystkim czterem agentom, i ujawnił ją każdemu dostawcy w następnym miesiącu w ramach skoordynowanego ujawniania. Anthropic potwierdził poprawkę w Claude Code 2.1.179 17 czerwca. Google poinformował AIR 4 sierpnia, że żadna poprawka nie zostanie wydana, ponieważ Gemini CLI jest wycofywane. 12 sierpnia zweryfikowano, że Codex 0.146.0 został naprawiony. Microsoft nie wydał poprawki dla GitHub Copilot.

Wersje poprawek są jedynym publicznym potwierdzeniem, że luka była rzeczywista w obu produktach, które ją naprawiły. Opublikowany wpis w changelogu Anthropic dla wersji 2.1.179 wymienia obsługę utraty połączenia, przewijanie w WSL2, poprawki globów piaskownicy i interfejsu, nie wspomina natomiast o przypinaniu, weryfikacji wtyczek ani jakiejkolwiek poprawce bezpieczeństwa. The Hacker News zauważył to samo, według relacji The Next Web. W momencie publikacji badania nie przypisano identyfikatora CVE, a nota badawcza Cloud Security Alliance dotycząca tej luki powtarza, że trzy miesiące po powiadomieniu dostawców żaden identyfikator nie istniał.

Czterech dostawców, trzy różne odpowiedzi

Google poszło dalej niż tylko odmówienie wydania poprawki. Oznaczyło Gemini CLI jako przestarzałe, co oznacza, że istniejące instalacje pozostaną narażone tak długo, jak długo ludzie będą je uruchamiać. Zaleca się migrację do Antigravity, nowszego agentowego środowiska programistycznego, którego — zdaniem AIR — atak nie dotyczy, ponieważ nie ma w nim przypinania SHA wtyczek z marketplace, które można obejść.

Stanowisko GitHuba znów jest inne. Rzecznik GitHuba powiedział serwisowi The Register, że platforma nie pozwala użytkownikom tworzyć nazw gałęzi lub tagów przypominających SHA commitów, oraz że „to złagodzenie zapewnia, że zgłoszona podatność nie może zostać wykorzystana na GitHubie”. AIR kwestionuje zakres tego złagodzenia, a nie jego istnienie: zdaniem badaczy marketplace'y można hostować na innych platformach, takich jak Bitbucket, a GitHub Copilot nadal obsługuje marketplace'y z tych platform, więc wariant z nazwą gałęzi pozostaje osiągalny dla użytkowników Copilota. AIR twierdzi również, że dokumentacja samej firmy Anthropic wymienia Bitbucket i samodzielnie hostowany git jako prawidłowe zaplecza marketplace'ów; obecna dokumentacja marketplace'ów Anthropic opisuje dodawanie marketplace'a z adresu URL repozytorium git, nie tylko z GitHuba. Microsoft nie odpowiedział na prośbę serwisu The Register o komentarz, a AIR poinformowało, że nie otrzymało odpowiedzi od Microsoftu od czasu zgłoszenia problemu w czerwcu, powołując się na liczbę ujawnień, którymi firma się zajmuje.

To jest spór o szerokość ekspozycji, a nie o to, czy błąd w ogóle istnieje. Mitygacja GitHuba to ograniczenie na poziomie hosta; ustalenie AIR jest takie, że sprawdzenie musi następować wewnątrz agenta, ponieważ pin jest rozwiązywany po stronie klienta.

Co jest ustalone, a co nie

• Ustalono: mechanizm. Publikacja AIR podaje dokładne polecenia git, regułę rozstrzygania ref-over-object, dwa warunki wymagane przez trik z gałęzią oraz osobny wariant FETCH_HEAD dla Gemini CLI. The Register, Help Net Security, Cybersecurity News, InfoWorld i The Next Web relacjonują to w ten sam sposób.

• Ustalono: dwie wersje z poprawkami. Anthropic potwierdził Claude Code 2.1.179 17 czerwca 2026 r., a Codex 0.146.0 firmy OpenAI został zweryfikowany jako naprawiony 12 sierpnia 2026 r., zgodnie z harmonogramem ujawnień AIR.

• Ustalono: dwa produkty nie miały poprawki w momencie ujawnienia. Google nie zamierza łatać Gemini CLI i wycofuje je; Microsoft nie wydał poprawki dla Copilota.

• Nie ustalono: niezależne odtworzenie. Każda opublikowana relacja prowadzi z powrotem do własnego wpisu blogowego AIR, a notatka badawcza Cloud Security Alliance wyraźnie nie opisuje walidacji technicznej przez stronę trzecią ani niezależnego odtworzenia exploita. Z tego powodu archiwum ocenia pewność tego rekordu na B.

• Nie ustalono: ile instalacji faktycznie było narażonych. „Miliony” to określenie AIR w nagłówku, a nie zmierzona liczba.

• Nie ustalono: czy aktualizacja dotkniętego agenta usuwa wtyczkę, która została już podmieniona, czy jedynie zapobiega kolejnej podmianie. Żadne opublikowane źródło tego nie rozstrzyga.

• Nie ustalono: żadnego zastosowania w realnym świecie. Żadne źródło w materiale nie donosi o wykorzystaniu, sondowaniu ani infrastrukturze atakującego, a archiwum odnotowuje rzeczywiste szkody jako nieprawdziwe. To brak doniesień, a nie dowód, że nic się nie wydarzyło.

Jedno sprawdzenie przeprowadzone przez stronę trzecią zawęża jednak praktyczny obraz. The Next Web, streszczając sprawdzenia The Hacker News, donosi, że wtyczki w katalogu społecznościowym Anthropic oraz w domyślnych katalogach Claude Code i Copilot wskazują na repozytoria GitHub, a automatyczna aktualizacja jest domyślnie włączona głównie w przypadku tych wbudowanych marketplace’ów. Ponieważ GitHub odrzuca nazwy gałęzi w kształcie SHA, wariant z nazwą gałęzi jest trudniej osiągalny dla użytkowników, którzy pozostają przy domyślnych katalogach. To rozumowanie nie obejmuje wariantu FETCH_HEAD w Gemini CLI, który nie zależy od tego, jak host nazywa gałęzie.

Jak musi wyglądać poprawka

Zalecanym przez AIR rozwiązaniem jest pojedyncza asercja: po wykonaniu checkoutu ustalić commit faktycznie obecny w drzewie roboczym i przerwać, chyba że jest równy przypiętemu SHA. Badacze podkreślają, że musi ona sprawdzać rozwiązany HEAD, a nie żądany ref, ponieważ ta różnica jest dokładnie tym, przez co prześlizguje się wariant Gemini CLI, oraz że musi działać wewnątrz agenta, ponieważ przypięcie jest rozwiązywane po stronie klienta i żaden marketplace nie może wyegzekwować gwarancji, którą reklamuje.

Praktyczne wskazówki dla zespołów obsługujących tych agentów, zaczerpnięte z AIR, Cybersecurity News oraz komentarzy analityków w InfoWorld:

• Zaktualizuj Claude Code do wersji 2.1.179 lub nowszej oraz Codex do wersji 0.146.0 lub nowszej. Aktualizacja to jedyne pełne rozwiązanie tam, gdzie dostępna jest poprawka.

• Wyłącz automatyczne aktualizacje wtyczek na każdym agencie, który nie ma poprawki. To ogranicza lukę z ataku bezklikowego do ręcznej reinstalacji, co jest zmniejszeniem ekspozycji, a nie naprawą.

• Przejdź z Gemini CLI na inne rozwiązanie, zamiast czekać na poprawkę, która według Google nie nadejdzie.

• Przeprowadź audyt inwentarza wtyczek i w miarę możliwości ogranicz źródła marketplace. AIR zauważa, że marketplace może osłabić wariant nazwy gałęzi, dopuszczając wyłącznie hosty, które odrzucają nazwy w kształcie SHA — w efekcie wyłącznie GitHub — ale blokuje to hosty oficjalnie obsługiwane przez agentów i nic nie daje w przypadku wariantu Gemini.

• Traktuj stację roboczą jako granicę ekspozycji. Wtyczki dziedziczą uprawnienia agenta, więc udany atak sięga do kodu źródłowego, kluczy SSH, poświadczeń chmurowych, tokenów CI/CD i wewnętrznych repozytoriów z uprawnieniami samego dewelopera. Pareekh Jain, główny analityk w Pareekh Consulting, powiedział InfoWorld, że zespoły ds. bezpieczeństwa powinny analizować logi EDR, git, CI/CD, cloud IAM i uwierzytelniania w poszukiwaniu nietypowych procesów, nieoczekiwanych plików wtyczek, zmienionych repozytoriów i podejrzanej aktywności git — i dodał, że te kroki zmniejszają ryzyko, nie usuwając podstawowej luki, którą przypisuje kodowi dostawcy. „Przedsiębiorstwa mogą wprowadzić kontrolę nad używaniem wtyczek” — powiedział InfoWorld — „ale nie mogą naprawić luki w sposobie, w jaki agent kodujący weryfikuje kod, który pobiera z repozytorium”.

Dlaczego błąd przypinania był tym, który się liczył

Przypinanie SHA było odpowiedzią branży na dokładnie ten rodzaj przejęcia, jaki AIR już zademonstrował: jeśli publiczne repozytorium zostanie skompromitowane, agent nadal uruchamia zaudytowany skrót, zamiast pobierać cokolwiek, co wypchnął atakujący. Plugin4Shell nie łamie skrótu. Pokazuje, że agenci rozwiązywali przypięcie do nazwy gałęzi, która jedynie wyglądała jak skrót, i nigdy nie porównywali wyniku. Wszystko, co wynika z tego założenia — procesy przeglądu, wewnętrzne listy dozwolonych, zaufanie programistów do przypiętej wersji — dziedziczy ten błąd.

Czego zapis nie potwierdza, to twierdzenie, że cokolwiek zostało zabrane. To luka, którą znaleziono i w dwóch z czterech przypadków naprawiono; żadne z zawartych w nim źródeł nie donosi o włamaniu, a produkty, które nie wydały poprawki, wciąż czekają. Najmniej satysfakcjonujące jest pytanie, które pozostaje otwarte: dla każdego, kto uruchomił wtyczkę na niezałatanym agencie, nie ma opublikowanego sposobu, by stwierdzić, czy kod, który został uruchomiony, był kodem, który zatwierdzili.