Dwie luki pokazują ryzyko AI i npm

Dwie różne luki, jeden problem: zaufanie

Dwa świeże przypadki z obszaru cyberbezpieczeństwa pokazują, że mechanizmy zaufania coraz częściej stają się celem atakujących. W pierwszym chodzi o kampanię na ekosystem npm, w której nadużyto procesu trusted publishing. W drugim o błąd w kilku popularnych AI coding agents, który pozwalał podmienić przypięty plugin na złośliwy kod.

Choć scenariusze są inne, wspólny mianownik jest ten sam: system uznaje coś za bezpieczne, bo pochodzi z właściwego miejsca, ma poprawny podpis albo jest przypięte do konkretnej wersji. Napastnik nie musi więc łamać zabezpieczeń wprost — wystarczy, że wykorzysta samą logikę zaufania.

npm: legalny proces, nielegalny efekt

W kampanii nazwanej GHAPPIER atakujący wykorzystali konto opiekuna pakietu @dforge-core/dforge-mcp. Przez około 105 minut 9 września mieli możliwość publikowania zmian, a jedna z wersji — 0.2.21 — zawierała wcześniej niezgłoszony loader.

Z pozoru wszystko wyglądało poprawnie. Pakiet został opublikowany z użyciem GitHub Actions i OIDC trusted publishing, a więc w modelu, który ma zwiększać bezpieczeństwo dystrybucji. Problem polegał na tym, że proweniencja potwierdza jedynie, gdzie artefakt został zbudowany, a nie czy jego źródło było uczciwe.

Atakujący:

• zmienili kilka linii tak, by każdy push do głównej gałęzi uruchamiał proces publikacji,
• po około 14 minutach przerobili workflow tak, aby publikował się bez nadzoru,
• wykorzystali podpisy i zaufaną ścieżkę CI, przez co publikacja przeszła przez standardowe mechanizmy kontroli.

W efekcie w pakiecie znalazł się jednolinijkowy loader ukryty w pliku o rozmiarze około 99 KB. Uruchamiał on wieloetapowy łańcuch prowadzący do ogólnego remote shella, który usuwał się z dysku podczas działania. Co ważne, ładunek aktywował się dopiero przy uruchomieniu serwera MCP, a nie już podczas instalacji.

Według analizy kampania objęła co najmniej 65 publicznych repozytoriów, 73 zainfekowane pliki i 22 konta. W jednym z przypadków drugi payload odpowiadał dokładnie znanej kampanii PolinRider, łączonej przez część badaczy z Koreą Północną, choć w tym materiale nie udało się tego potwierdzić niezależnie.

AI coding agents: podmieniony plugin mimo przypiętej wersji

Druga opisana luka dotyczy czterech popularnych agentów do programowania z użyciem AI. Badacze wskazali, że osoba kontrolująca repozytorium pluginu może sprawić, iż agent pobierze inny kod niż ten, który miał być przypięty do konkretnego commita.

W praktyce problem wynikał z tego, że agent pobierał wskazany snapshot, ale nie weryfikował, czy kod, który finalnie instaluje, rzeczywiście odpowiada temu hashowi. Jeśli serwer git pozwala na tworzenie gałęzi o nazwie podobnej do SHA commita, można podstawić inną zawartość pod pozornie zaufany adres.

To oznaczało, że złośliwy plugin mógł działać z tymi samymi uprawnieniami co użytkownik agenta, a więc mieć dostęp do:

• plików lokalnych,
• zapisanych poświadczeń,
• systemów, do których użytkownik ma logowanie.

Badacze wskazali też, że problem nie dotyczy wszystkich hostów w jednakowy sposób. W przypadku GitHub taki trick z nazwą gałęzi nie powinien działać, bo platforma blokuje nazwy łudząco podobne do hashy commitów. Inaczej jest natomiast na serwisach, które takich ograniczeń nie mają, oraz w części wdrożeń opartych o własne serwery git.

Szczególny wariant dotyczył także Gemini CLI, gdzie można było wykorzystać nazwę FETCH_HEAD. Z kolei w przypadku pozostałych narzędzi sytuacja wygląda różnie:

• Claude Code — luka miała zostać załatana w wersji 2.1.179,
• Codex — poprawka pojawiła się w wersji 0.146.0,
• GitHub Copilot — według badaczy nie otrzymał jeszcze poprawki,
• Gemini CLI — według badaczy nie będzie łagodzony, a użytkownicy są kierowani do Antigravity.

Dlaczego to ważne

Oba przypadki dobrze pokazują, że bezpieczeństwo ekosystemów developerskich nie kończy się na podpisie, pinowaniu wersji czy zaufanym CI. Jeśli napastnik przejmie konto maintenera, repozytorium albo możliwość publikacji dodatku, może wykorzystać właśnie to, co miało chronić użytkownika.

W świecie, w którym coraz więcej pracy wykonują agenci AI i automatyczne procesy publikacji, kontrola źródła, integralności i zachowania workflow staje się równie ważna jak sam podpis kryptograficzny.

Co można zrobić

W przypadku kampanii npm zalecono m.in.:

• przypięcie pakietu do wersji 0.2.22,
• traktowanie lockfile wskazującego 0.2.21 jako sygnału ostrzegawczego,
• przeszukanie środowisk pod kątem śladów pozostawionych przez łańcuch ataku,
• monitorowanie zmian w sekcji wyzwalającej release workflow.

W przypadku agentów AI kluczowe jest aktualizowanie oprogramowania do wersji z poprawkami tam, gdzie one istnieją, oraz ostrożność przy korzystaniu z pluginów zewnętrznych, zwłaszcza hostowanych poza rygorystycznie kontrolowanymi repozytoriami.

Wspólny wniosek

Te dwa incydenty pokazują, że zaufanie w łańcuchu dostaw oprogramowania jest dziś równie cennym celem jak dane czy infrastruktura. Atakujący nie zawsze muszą przełamywać zabezpieczenia — czasem wystarczy, że sprawią, iż system sam uzna ich działanie za legalne.