gik|iewicz

TL;DR: 17 lutego 2026 atakujący opublikował złośliwą wersję popularnego narzędzia AI Cline na npm. Przez 8 godzin około 4000 deweloperów nieświadomie zainstalowało OpenClaw – osobnego agenta AI z pełnym dostępem do systemu. Co najważniejsze: atakujący zdobył token npm, wstrzykując prompt w tytuł GitHub Issue, który został odczytany i wykonany przez bota AI do triage’u.

Co się Stało? Atak w Liczbach

Szczegóły Ataku: Jak to się Stało?

Atak, nazwany przez Snyk „Clinejection”, to nie pojedyncza luka, ale pięć połączonych luk bezpieczeństwa tworzących jedną eksploatację. Wymagał jedynie otwarcia GitHub Issue.

Krok 1: Prompt Injection przez Tytuł Issue’a

Cline wdrożył workflow triage’u issue’ów zasilany AI, używając claude-code-action od Anthropic. Workflow był skonfigurowany z allowed_non_write_users: "*", co oznaczało, że każdy użytkownik GitHub mógł go wywołać, otwierając issue.

Tytuł issue’a był interpolowany bezpośrednio do promptu Claude’a przez ${{ github.event.issue.title }} – bez jakiejkolwiek sanityzacji.

28 stycznia atakujący stworzył Issue #8904 z tytułem zaprojektowanym tak, aby wyglądał jak raport wydajności, ale zawierał ukrytą instrukcję: zainstaluj pakiet z konkretnego repozytorium GitHub.

Krok 2: Bot AI Wykonuje Dowolny Kod

Claude zinterpretował wstrzykniętą instrukcję jako legitimną i uruchomił npm install wskazujący na fork atakującego – repozytorium typosquattingowe (glthub-actions/cline, zwróć uwagę na brakujące 'i’ w 'github’).

Package.json w tym forku zawierał skrypt preinstall, który pobierał i wykonywał zdalny skrypt shellowy.

Krok 3: Cache Poisoning

Skrypt shellowy rozmieścił Cacheract – narzędzie do zatruwania cache’a GitHub Actions. Zalało cache ponad 10 GB śmieciowych danych, wywołując politykę LRU (Least Recently Used) GitHub i usuwając legalne wpisy cache’a.

Zatrute wpisy zostały stworzone tak, aby pasować do wzorca klucza cache’a używanego przez workflow nightly release Cline’a.

Krok 4: Kradzież Poświadczeń

Gdy workflow nightly release uruchomił się i przywrócił node_modules z cache’a, otrzymał skompromitowaną wersję. Workflow release’a miał dostęp do:

• NPM_RELEASE_TOKEN
• VSCE_PAT (VS Code Marketplace)
• OVSX_PAT (OpenVSX)

Wszystkie trzy zostały wyeksfiltrowane.

Krok 5: Złośliwa Publikacja

Używając skradzionego tokena npm, atakujący opublikował cline@2.3.0 z hookiem postinstall instalującym OpenClaw. Skompromitowana wersja była dostępna przez 8 godzin, zanim automatyczne monitorowanie StepSecurity ją oflagowało – około 14 minut po publikacji.

Dlaczego Istniejące Zabezpieczenia Nie Zadziałały?

To, co czyni ten atak wyjątkowym, to fakt, że żadne standardowe zabezpieczenia go nie wykryły:

Atak wykorzystał lukę między tym, co deweloperzy myślą, że instalują (konkretna wersja Cline), a tym, co faktycznie się wykonuje (dowolne skrypty lifecycle z pakietu i wszystko, co on tranzytywnie instaluje).

Nowy Wzorzec: AI Instaluje AI

To, co czyni Clinejection wyjątkowym, to wynik: jedno narzędzie AI po cichu instaluje drugiego agenta AI na maszynach deweloperów.

To tworzy problem rekurencji w łańcuchu dostaw:

1. Deweloper ufa Narzędziu A (Cline)
2. Narzędzie A jest skompromitowane, by zainstalować Narzędzie B (OpenClaw)
3. Narzędzie B ma własne możliwości – wykonanie shell, dostęp do poświadczeń, instalacja jako persistent daemon – które są niezależne od Narzędzia A i niewidoczne dla pierwotnej decyzji zaufania dewelopera

OpenClaw po zainstalowaniu mógł:

• Czytać poświadczenia z ~/.openclaw/
• Wykonywać komendy shell przez Gateway API
• Instalować się jako persistent system daemon przetrwujący restarty

To jest odpowiednik „confused deputy” w łańcuchu dostaw: deweloper autoryzuje Cline do działania w swoim imieniu, a Cline (przez kompromitację) deleguje tę władzę do zupełnie osobnego agenta, którego deweloper nigdy nie ocenił, nie skonfigurował i na którego nie wyraził zgody.

Historia Odkrycia Luki: 5 Tygodni Ciszy

Historia tego ataku jest jeszcze bardziej niepokojąca, gdy pozna się jej pełny przebieg.

Badacz bezpieczeństwa Adnan Khan odkrył łańcuch luk pod koniec grudnia 2025 i zgłosił go przez GitHub Security Advisory 1 stycznia 2026. Wysłał wielokrotne follow-up’y przez pięć tygodni. Żaden nie otrzymał odpowiedzi.

Gdy Khan publicznie ujawnił lukę 9 lutego, Cline załatał ją w ciągu 30 minut. Ale rotacja poświadczeń została zbotowana – zespół usunął zły token, zostawiając eksponowany aktywny.

Atakujący już eksfiltrował poświadczenia, a token npm pozostał ważny wystarczająco długo, by opublikować skompromitowany pakiet sześć dni później.

Ważne: Khan nie był atakującym. Osobny, nieznany aktor znalazł proof-of-concept Khana na jego repozytorium testowym i uzbroił go przeciwko Cline bezpośrednio.

Reakcje Branży: Co Mówią Eksperci?

Atak wywołał znaczące poruszenie w społeczności bezpieczeństwa i AI.

StepSecurity, która wykryła skompromitowany pakiet, podkreśla znaczenie monitorowania publikacji npm i flagowania anomalii takich jak brak metadanych provenance.

Endor Labs scharakteryzowała payload jako bliższy proof-of-concept niż uzbrojonemu atakowi – ale mechanizm jest tym, co ma znaczenie. Jak zauważa grith.ai w swojej analizie: „Następny payload nie będzie proof-of-concept.”

Snyk, która nazwała atak „Clinejection”, opublikowała szczegółową analizę techniczną, podkreślając, że atak komponuje dobrze zrozumiałe luki w coś nowego.

Kluczowy wniosek z analizy grith.ai:

To jest odpowiednik „confused deputy” w łańcuchu dostaw: deweloper autoryzuje Cline do działania w swoim imieniu, a Cline (przez kompromitację) deleguje tę władzę do zupełnie osobnego agenta, którego deweloper nigdy nie ocenił, nie skonfigurował i na którego nie wyraził zgody.

Co Cline Zmienił po Ataku?

W swoim post-mortem Cline opisał kilka kroków remediacji:

1. Eliminacja cache’a GitHub Actions z workflow obsługujących poświadczenia
2. Adopcja OIDC provenance attestations dla publikacji npm – eliminacja długowiecznych tokenów
3. Wymagania weryfikacji dla rotacji poświadczeń
4. Praca nad formalnym procesem disclosure luk bezpieczeństwa z SLA
5. Zlecenie audytów bezpieczeństwa podmiotom zewnętrznym infrastruktury CI/CD

Te są znaczącymi usprawnieniami. Sama migracja OIDC zapobiegłaby atakowi – skradziony token nie może publikować pakietów, gdy provenance wymaga kryptograficznego zaświadczenia od konkretnego workflow GitHub Actions.

Analiza: Co Ten Atak Mówi o Przyszłości Bezpieczeństwa AI?

Clinejection to nie tylko incydent – to przepowiednia tego, jak będą wyglądać ataki na łańcuch dostaw w erze AI. Wyróżnia się trzema cechami, które będą definiować przyszłe zagrożenia:

Po pierwsze: punkt wejścia to język naturalny. Tradycyjne ataki wymagały znajomości technicznej – exploitów, buffer overflow, SQL injection. Clinejection wymagał jedynie umiejętności napisania przekonującego tekstu w tytule GitHub Issue. Ta bariera wejścia drastycznie spada, otwierając pole dla szerszego grona atakujących.

Po drugie: kompozycja znanych luk. Żadna z pięciu luk nie była nowa – prompt injection, cache poisoning, credential theft to wszystkie udokumentowane klasy ataków. Nowość polega na ich połączeniu w łańcuch, gdzie każde ogniwo napędza następne. To sugeruje, że przyszłe ataki będą coraz bardziej wyrafinowanymi kompozycjami, a nie pojedynczymi exploitami.

Po trzecie: AI jako wektor i cel. Agent AI był zarówno narzędziem ataku (wykonywał złośliwe instrukcje), jak i jego celem (kompromitacja łańcucha dostaw narzędzia AI). Ta rekurencja – AI kompromitujące AI – będzie się nasilać wraz z adopcją agentów w CI/CD.

Co to oznacza dla deweloperów i organizacji? Przede wszystkim konieczność fundamentalnej zmiany myślenia o zaufaniu. Zaufanie do narzędzia AI nie może być binarne – musi być kontekstowe i ograniczone. Per-syscall interception, polityki egress i weryfikacja provenance to nie opcje – to konieczności.

Pytanie nie brzmi „czy Twój projekt zostanie zaatakowany przez AI”, ale „kiedy i czy będziesz gotowy”.

Dlaczego To Ważne dla Każdego Dewelopera?

Clinejection to atak na łańcuch dostaw, ale to także problem bezpieczeństwa agentów. Punkt wejścia był językiem naturalnym w tytule GitHub Issue. Pierwszym ogniwem łańcucha był bot AI, który zinterpretował niezaufany tekst jako instrukcję i wykonał go z przywilejami środowiska CI.

To ten sam strukturalny wzorzec, o którym pisano w kontekście:

• MCP tool poisoning (MCP Servers)
• Agent skill registries
• Prompt injection w agentach AI

Różnica polega na tym, że agent nie był lokalnym asystentem kodowania dewelopera. Był to zautomatyzowany workflow CI, który uruchamiał się na każdym nowym issue, z dostępem do shell i cache’owanych poświadczeń.

Promień rażenia nie był jedną maszyną dewelopera – był to cały potok publikacji projektu.

Architekturalne Pytanie: Co z Tego Wynika?

Każdy zespół wdrażający agentów AI w CI/CD – do triage’u issue’ów, code review, automatycznego testowania czy jakiegokolwiek innego workflow – ma to samo narażenie.

Agent przetwarza niezaufane dane wejściowe (issues, PRs, komentarze) i ma dostęp do sekretów (tokeny, klucze, poświadczenia). Pytanie brzmi: czy cokolwiek ocenia to, co agent robi z tym dostępem?

Rozwiązania takie jak per-syscall interception wyłapują tę klasę ataków na warstwie operacji. Gdy bot AI triage’u próbuje uruchomić npm install z nieoczekiwanego repozytorium, operacja jest oceniana względem polityki przed wykonaniem – niezależnie od tego, co mówił tytuł issue’a.

Gdy skrypt lifecycle próbuje eksfiltrować poświadczenia do zewnętrznego hosta, egress jest blokowany.

Punkt wejścia się zmienia. Operacje – nie.

Jak się Chronić przed Podobnymi Atakami?

Na podstawie analizy ataku Clinejection, oto kluczowe rekomendacje:

Dla użytkowników narzędzi AI

• Weryfikuj pochodzenie pakietów – sprawdzaj, czy pakiet używa OIDC provenance
• Ograniczaj uprawnienia – używaj narzędzi AI w izolowanych środowiskach
• Monitoruj instalacje – sprawdzaj, co faktycznie instalujesz przez npm/yarn
• Aktualizuj świadomie – nie aktualizuj automatycznie wszystkich zależności

Dla maintainerów projektów

• Sanityzuj dane wejściowe – nigdy nie interpoluj niezaufanych danych bezpośrednio do promptów
• Używaj OIDC provenance – eliminuj długowieczne tokeny
• Stwórz proces disclosure z jasnymi SLA
• Oddziel sekrety od cache’a – nie przechowuj poświadczeń w cache’owanych artefaktach
• Weryfikuj rotację poświadczeń – upewnij się, że właściwy token został unieważniony

Dla organizacji

• Wdróż polityki egress – blokuj nieautoryzowane połączenia wychodzące
• Monitoruj CI/CD – flaguj anomalie w workflow
• Edukuj zespoły o ryzykach prompt injection i supply chain attacks

Powiązane Artykuły

Ten atak łączy się z szerszym tematem bezpieczeństwa narzędzi AI:

• Claude Code Security znalazł 500+ zero-day vulnerabilities
• AI Coding Assistants 2026: Claude vs Cursor vs Windsurf vs Copilot
• MCP (Model Context Protocol) w 2026 – Kompletny Przewodnik
• MCP Servers: Jak podłączyć Claude do całego tech-stacku

FAQ: Najczęściej Zadawane Pytania

Czym jest Clinejection?

Clinejection to atak na łańcuch dostaw nazwany przez Snyk, który wykorzystuje prompt injection w tytułach GitHub Issues do kompromitacji narzędzi AI. Atakujący wstrzykuje złośliwą instrukcję w tytuł issue’a, który jest odczytywany przez bota AI do triage’u i wykonywany z uprawnieniami środowiska CI.

Czy byłem ofiarą tego ataku?

Jeśli instalowałeś lub aktualizowałeś Cline między 17 lutego 2026 a czasem usunięcia pakietu (~8 godzin), na Twojej maszynie mógł zostać zainstalowany OpenClaw. Sprawdź, czy masz katalog ~/.openclaw/ lub globalnie zainstalowany pakiet openclaw przez npm list -g openclaw.

Jak sprawdzić, czy mam zainstalowany OpenClaw?

Uruchom w terminalu: npm list -g openclaw. Jeśli pakiet jest zainstalowany, odinstaluj go przez npm uninstall -g openclaw i usuń katalog ~/.openclaw/ jeśli istnieje. Zaleca się również zmianę wszelkich poświadczeń, które mogły być dostępne dla agenta.

Dlaczego standardowe zabezpieczenia nie wykryły ataku?

Atak wykorzystywał legalny pakiet (OpenClaw) bez malware’u, zmieniał tylko jedną linię w package.json (identyczna binarka CLI), nie używał OIDC provenance i działał w hooku postinstall, który nie wymaga potwierdzenia użytkownika.

Czy Cline jest teraz bezpieczny?

Cline wdrożył znaczące usprawnienia bezpieczeństwa: eliminację cache’a GitHub Actions z workflow obsługujących poświadczenia, adopcję OIDC provenance attestations, wymogi weryfikacji dla rotacji poświadczeń i pracę nad formalnym procesem disclosure. Migracja OIDC sama w sobie zapobiegłaby temu atakowi.

Źródła

• grith.ai: A GitHub Issue Title Compromised 4,000 Developer Machines
• Snyk: How „Clinejection” Turned an AI Bot into a Supply Chain Attack
• StepSecurity: Cline Supply Chain Attack Detected