Archiwa: DevSecOps - Strona 7 z 18 - Security Bez Tabu

NIST rozpoczyna testy frontier AI pod kątem ryzyk cyberbezpieczeństwa

Cybersecurity news

Wprowadzenie do problemu / definicja

Amerykański National Institute of Standards and Technology zapowiedział uruchomienie przedwdrożeniowych ocen zaawansowanych modeli sztucznej inteligencji dostarczanych przez Google, Microsoft i xAI. Celem programu jest sprawdzenie, czy tzw. frontier models, czyli najbardziej zaawansowane generacje systemów AI, mogą tworzyć istotne ryzyka dla cyberbezpieczeństwa, w tym wspierać wyszukiwanie podatności, automatyzować część działań ofensywnych lub przyspieszać rozwój technik ataku.

To ważny sygnał, że bezpieczeństwo generatywnej AI przestaje być traktowane wyłącznie jako problem etyczny lub regulacyjny. Coraz wyraźniej staje się także zagadnieniem operacyjnym, związanym z realnym wpływem modeli na krajobraz zagrożeń.

W skrócie

Nowa inicjatywa realizowana przez Center for AI Standards and Innovation ma umożliwić rządowi USA testowanie modeli jeszcze przed ich publicznym wdrożeniem. Program obejmuje współpracę z trzema dużymi dostawcami technologii oraz wymianę informacji, która ma pomóc w poprawie bezpieczeństwa produktów.

Istotnym elementem ma być również udział międzyagencyjnej grupy zadaniowej, zdolnej do prowadzenia ewaluacji także w środowiskach o podwyższonym poziomie poufności. W praktyce oznacza to próbę zbudowania bardziej systemowego nadzoru nad cybernetycznymi skutkami rozwoju zaawansowanej AI.

  • Testy obejmą modele od Google, Microsoft i xAI.
  • Oceny mają być prowadzone przed wdrożeniem publicznym.
  • Priorytetem jest identyfikacja zagrożeń dla cyberbezpieczeństwa.
  • Program może stać się podstawą przyszłych standardów oceny ryzyka AI.

Kontekst / historia

Decyzja NIST wpisuje się w szerszą zmianę podejścia administracji USA do bezpieczeństwa sztucznej inteligencji. Wcześniejsze mechanizmy przeglądu bezpieczeństwa bywały krytykowane jako nadmiernie obciążające dla sektora technologicznego, jednak szybkie tempo rozwoju modeli ogólnego przeznaczenia zwiększyło presję na tworzenie praktycznych procedur testowych.

Impulsem do przyspieszenia działań stały się publiczne dyskusje o modelach zdolnych do wspierania analizy podatności, identyfikowania poważnych błędów w oprogramowaniu oraz zwiększania produktywności operatorów działań ofensywnych. Z perspektywy państwa oznacza to konieczność przejścia od deklaracji o odpowiedzialnej AI do rzeczywistej weryfikacji możliwości modeli w scenariuszach związanych z bezpieczeństwem narodowym, ochroną infrastruktury krytycznej i bezpieczeństwem oprogramowania.

Analiza techniczna

Z technicznego punktu widzenia przedwdrożeniowa ocena modeli AI może obejmować kilka obszarów. Pierwszy dotyczy zdolności modelu do generowania lub usprawniania działań ofensywnych, takich jak tworzenie exploitów, analiza kodu pod kątem podatności, rekonstrukcja łańcuchów ataku czy automatyzacja rekonesansu.

Drugi obszar to badanie podatności samego modelu na nadużycia. Chodzi tu o odporność na jailbreaki, omijanie guardrailów, eskalację uprawnień w środowiskach agentowych oraz generowanie niebezpiecznych instrukcji mimo zastosowanych zabezpieczeń.

Trzecim elementem jest ocena, czy model znacząco obniża próg wejścia dla mniej zaawansowanych aktorów zagrożeń. Nawet jeśli system nie potrafi samodzielnie przeprowadzić złożonego ataku, może zwiększać skuteczność operatora przez szybsze tworzenie skryptów, analizę logów, streszczanie dokumentacji technicznej, modyfikację złośliwego oprogramowania czy wskazywanie prawdopodobnych punktów wejścia.

Kluczowym wyzwaniem pozostaje metodologia. Sama zapowiedź testów nie odpowiada jeszcze na pytania o zakres scenariuszy, definicję sukcesu ataku, poziom dopuszczalnej skuteczności, kryteria klasyfikacji ryzyka ani sposób raportowania wyników. Bez spójnych modeli zagrożeń i transparentnych benchmarków porównywanie wyników między dostawcami może być utrudnione.

Znaczenie ma także możliwość prowadzenia testów przez przedstawicieli różnych agencji rządowych, potencjalnie również w środowiskach niejawnych. Sugeruje to, że ewaluacje mogą wykraczać poza klasyczny red teaming i obejmować scenariusze związane z obroną sektora publicznego, łańcuchami dostaw oprogramowania oraz wpływem modeli na zdolności przeciwników państwowych.

Konsekwencje / ryzyko

Dla dostawców AI oznacza to wzrost oczekiwań w zakresie podejścia secure-by-design, dokumentowania ograniczeń modeli oraz gotowości do współpracy z administracją publiczną. W dłuższej perspektywie testy przedwdrożeniowe mogą stać się rynkowym standardem dla najbardziej zaawansowanych systemów, nawet jeśli formalnie pozostaną dobrowolne.

Dla zespołów bezpieczeństwa znaczenie tej inicjatywy jest równie duże. Zaawansowane modele mogą wspierać zarówno obronę, jak i działania ofensywne. Ryzyko dotyczy zwłaszcza przyspieszenia prac nad exploitami, automatyzacji analizy podatności zero-day, zwiększenia skali kampanii phishingowych oraz ułatwienia tworzenia narzędzi dla mniej doświadczonych operatorów.

W rezultacie przewaga obrońców nie będzie zależeć wyłącznie od klasycznych mechanizmów detekcji. Coraz większą rolę odegra zdolność monitorowania sposobów użycia narzędzi AI w organizacji oraz ocena wpływu modeli na procesy bezpieczeństwa, rozwój oprogramowania i zarządzanie incydentami.

Rekomendacje

Organizacje powinny już teraz uwzględnić modele generatywne i agentowe w swoich programach zarządzania ryzykiem. Dotyczy to zarówno środowisk korporacyjnych, jak i sektora publicznego oraz operatorów infrastruktury krytycznej.

  • Klasyfikować zastosowania AI według poziomu ryzyka operacyjnego i bezpieczeństwa.
  • Testować odporność wdrażanych modeli na prompt injection, data exfiltration i omijanie zabezpieczeń.
  • Ograniczać uprawnienia agentów AI zgodnie z zasadą najmniejszych uprawnień.
  • Monitorować logi użycia modeli pod kątem prób generowania treści ofensywnych lub niezgodnych z polityką.
  • Prowadzić red teaming obejmujący scenariusze cyberataków wspieranych przez AI.
  • Aktualizować procedury AppSec i DevSecOps o przypadki użycia kodu wygenerowanego przez modele.
  • Weryfikować, czy dostawcy publikują informacje o testach bezpieczeństwa, guardrailach i znanych ograniczeniach modeli.

Szczególnie ważne będzie przygotowanie procedur walidacji narzędzi AI przed ich dopuszczeniem do środowisk wrażliwych, takich jak systemy SOC, platformy automatyzacji, repozytoria kodu czy środowiska administracyjne.

Podsumowanie

Zapowiedziane przez NIST testy modeli Google, Microsoft i xAI pokazują, że ocena cyberbezpieczeństwa frontier AI wchodzi w nową fazę. Zamiast ogólnych zasad pojawia się nacisk na praktyczne, przedwdrożeniowe badania ryzyka, które mogą dostarczyć bardziej użytecznych danych dla administracji i rynku.

Największym wyzwaniem pozostaje jednak nie sama współpraca z producentami, lecz zdefiniowanie mierzalnych standardów testowania i jasnych modeli zagrożeń. Jeśli program zostanie rozwinięty w spójny framework oceny, może stać się jednym z kluczowych punktów odniesienia dla bezpieczeństwa zaawansowanych systemów AI.

Źródła

Złośliwy pakiet PyTorch Lightning na PyPI uruchamiał stealer już przy imporcie biblioteki

Cybersecurity news

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania pozostają jednym z najpoważniejszych zagrożeń dla środowisk deweloperskich, badawczych i produkcyjnych. Najnowszy incydent związany z pakietem PyTorch Lightning pokazuje, że nawet popularna biblioteka wykorzystywana w projektach AI może zostać użyta jako nośnik złośliwego kodu.

Problem dotyczył wydania lightning==2.6.3 opublikowanego w repozytorium PyPI. W pakiecie umieszczono ukryty mechanizm wykonania, który prowadził do pobrania i uruchomienia malware kradnącego poświadczenia oraz inne wrażliwe dane z systemu ofiary.

W skrócie

  • Wersja 2.6.3 pakietu Lightning została uznana za złośliwą.
  • Aktywacja następowała automatycznie już po wykonaniu import lightning.
  • Mechanizm uruchamiał proces w tle, pobierał runtime Bun i wykonywał zaciemniony skrypt JavaScript.
  • Ładunek był ukierunkowany na kradzież plików .env, tokenów GitHub, sekretów chmurowych oraz danych z przeglądarek.
  • Użytkownikom zalecono natychmiastowe usunięcie pakietu i rotację wszystkich zagrożonych sekretów.

Kontekst / historia

PyTorch Lightning, rozwijany obecnie jako Lightning, to szeroko stosowany framework dla uczenia głębokiego i trenowania modeli AI. Ze względu na dużą popularność biblioteki każdy incydent bezpieczeństwa dotyczący jej procesu publikacji może mieć szeroki wpływ na organizacje wykorzystujące narzędzia MLOps, notebooki badawcze i pipeline’y CI/CD.

Incydent został publicznie nagłośniony 30 kwietnia 2026 roku, gdy wykryto, że wydanie 2.6.3 zawiera elementy niezgodne z oczekiwanym zachowaniem biblioteki. Złośliwe wydanie zostało następnie wycofane, a użytkownikom wskazano bezpieczne wersje do dalszego użycia.

To klasyczny przykład ataku supply chain. Napastnik nie musi bezpośrednio włamywać się do środowiska końcowego ofiary, jeśli uda mu się umieścić złośliwy kod w zaufanej zależności używanej przez programistów, badaczy danych i systemy automatyzacji.

Analiza techniczna

Technicznie incydent był szczególnie groźny, ponieważ próg aktywacji był bardzo niski. Wystarczało samo zaimportowanie biblioteki, aby uruchomić ukryty kod. Taki model działania znacząco utrudnia wykrycie zagrożenia, ponieważ użytkownik nie musi wywoływać żadnej podejrzanej funkcji.

Zgodnie z analizą, mechanizm inicjalizacyjny tworzył proces potomny uruchamiany w tle. Działanie było zaprojektowane tak, aby ograniczyć widoczność anomalii: tłumiono komunikaty standardowego wyjścia i błędów, co zmniejszało szansę na szybkie zauważenie incydentu.

Następny etap obejmował uruchomienie komponentu pobierającego zewnętrzny runtime Bun, a następnie wykonanie silnie zaciemnionego pliku router_runtime.js. Tego rodzaju zaciemnianie utrudnia analizę statyczną, detekcję sygnaturową oraz szybką ocenę pełnego zakresu funkcji złośliwego kodu.

Analiza artefaktu wskazywała na funkcjonalność typową dla stealerów informacji. Zaobserwowano odniesienia do:

  • plików .env i zmiennych środowiskowych,
  • mechanizmów wykonywania poleceń systemowych,
  • danych przechowywanych przez Chrome, Firefox i Brave,
  • webhooków oraz kanałów eksfiltracji danych,
  • interfejsów usług AWS, Azure i Google Cloud,
  • endpointów powiązanych z GitHub API.

Szczególnie niepokojące było odwołanie do adresu 169.254.169.254, czyli lokalnego endpointu metadanych AWS IMDS. W praktyce oznacza to możliwość pozyskania tymczasowych poświadczeń przypisanych do instancji i workloadów działających w chmurze. Dla organizacji uruchamiających trening modeli, zadania inferencyjne lub pipeline’y budowania artefaktów taki wektor stanowi bardzo wysokie ryzyko.

Istotne jest również to, że złośliwe pliki znajdowały się bezpośrednio w opublikowanym artefakcie pakietu wraz z odpowiednimi wpisami integralności. Wskazuje to, że problem nie wynikał z lokalnej infekcji po stronie pojedynczego użytkownika, lecz był częścią oficjalnie dostarczonego wydania.

Konsekwencje / ryzyko

Skutki takiego incydentu mogą wykraczać daleko poza pojedynczą stację roboczą dewelopera. Jeśli podatna wersja została zainstalowana lub zaimportowana w środowisku roboczym, organizacja mogła narazić się na ujawnienie szerokiego zestawu danych uwierzytelniających i operacyjnych.

  • Klucze API i sekrety aplikacyjne.
  • Tokeny dostępu do repozytoriów kodu.
  • Poświadczenia do usług chmurowych.
  • Dane sesyjne i zapisane hasła z przeglądarek.
  • Zawartość zmiennych środowiskowych oraz lokalnych konfiguracji.

Największe ryzyko dotyczy środowisk, w których Lightning był importowany automatycznie podczas testów, budowy obrazów, uruchamiania notebooków, zadań treningowych lub pracy kontenerów CI/CD. W takich przypadkach kompromitacja mogła prowadzić do wtórnych naruszeń, takich jak przejęcie kont chmurowych, dostęp do repozytoriów, modyfikacja pipeline’ów czy dalsze rozprzestrzenianie się ataku wewnątrz organizacji.

Incydent pokazuje też, jak niebezpieczne są zależności uruchamiające kod już na etapie importu modułu. To zachowanie często omija intuicyjne założenia administratorów i programistów, którzy koncentrują się na funkcjach wywoływanych jawnie, a nie na logice inicjalizacyjnej biblioteki.

Rekomendacje

Organizacje, które mogły korzystać z lightning==2.6.3, powinny traktować incydent jako potencjalne naruszenie poufności danych. Zalecana jest szybka reakcja obejmująca zarówno działania techniczne, jak i operacyjne.

  • Natychmiast usunąć wersję 2.6.3 ze wszystkich środowisk deweloperskich, testowych i produkcyjnych.
  • Zweryfikować historię instalacji pakietów w stacjach roboczych, notebookach, kontenerach i pipeline’ach CI/CD.
  • Przeprowadzić rotację wszystkich sekretów, które mogły znajdować się w plikach .env, zmiennych środowiskowych, przeglądarkach lub konfiguracjach chmurowych.
  • Unieważnić i ponownie wydać tokeny GitHub, klucze API oraz poświadczenia AWS, Azure i GCP.
  • Przeanalizować logi sieciowe i telemetrię EDR pod kątem nietypowych połączeń wychodzących oraz uruchamiania procesów powiązanych z Bun i zaciemnionymi skryptami JavaScript.
  • Skontrolować obrazy kontenerowe, cache zależności i artefakty buildów, aby wykluczyć utrwalenie złośliwych komponentów.
  • Wdrożyć silniejsze kontrole supply chain, w tym pinning wersji, skanowanie zależności, weryfikację integralności i podpisywanie artefaktów.
  • Ograniczyć dostęp workloadów do metadanych instancji, jeśli nie jest on wymagany, oraz stosować zasadę najmniejszych uprawnień.

Dobrą praktyką pozostaje również izolowanie środowisk budowy i treningu modeli od lokalnych przeglądarek oraz przechowywanych na stacjach roboczych sekretów. Taka segmentacja zmniejsza skutki potencjalnej kompromitacji zależności zewnętrznych.

Podsumowanie

Incydent z PyTorch Lightning to kolejny przykład dojrzałego ataku na łańcuch dostaw, w którym złośliwy kod został osadzony bezpośrednio w popularnym pakiecie ekosystemu programistycznego. Najgroźniejszym elementem była automatyczna aktywacja po zwykłym imporcie biblioteki oraz szeroki zakres danych objętych próbą kradzieży.

Dla zespołów DevSecOps, MLOps i administratorów bezpieczeństwa to wyraźny sygnał, że biblioteki AI i narzędzia data science muszą być objęte takimi samymi mechanizmami kontroli jak krytyczne komponenty backendowe. W praktyce oznacza to konieczność wzmacniania ochrony supply chain, monitorowania zależności i szybkiego reagowania na incydenty dotyczące publicznych rejestrów pakietów.

Źródła

  1. BleepingComputer — Backdoored PyTorch Lightning package drops credential stealer — https://www.bleepingcomputer.com/news/security/backdoored-pytorch-lightning-package-drops-credential-stealer/
  2. Lightning-AI / pytorch-lightning — Possible supply chain attack on version 2.6.3 — https://github.com/Lightning-AI/pytorch-lightning/issues/21689

Anthropic uruchamia Claude Security, odpowiadając na wzrost exploitów wspieranych przez AI

Cybersecurity news

Wprowadzenie do problemu / definicja

Rosnące możliwości generatywnej sztucznej inteligencji coraz mocniej wpływają na krajobraz cyberbezpieczeństwa. Szczególnie widoczne jest to w obszarze analizy kodu, wyszukiwania podatności oraz skracania czasu potrzebnego do przejścia od wykrycia luki do przygotowania działającego exploitu. W odpowiedzi na ten trend Anthropic zaprezentował Claude Security, czyli rozwiązanie ukierunkowane na wsparcie zespołów bezpieczeństwa w wykrywaniu słabości w kodzie i przyspieszaniu procesu remediacji.

Nowe narzędzie jest pozycjonowane jako defensywna odpowiedź na zagrożenia wynikające z coraz szerszego wykorzystania AI w działaniach ofensywnych. Celem ma być ograniczenie przewagi, jaką uzyskują atakujący dzięki automatyzacji analizy podatności i szybszemu tworzeniu exploitów.

W skrócie

Claude Security został udostępniony w publicznej becie dla klientów Claude Enterprise. Rozwiązanie ma działać bez potrzeby budowania własnych agentów czy przeprowadzania złożonej integracji przez API, co obniża próg wejścia dla organizacji chcących szybko przetestować jego możliwości.

  • umożliwia skanowanie repozytoriów, katalogów i wybranych gałęzi kodu,
  • identyfikuje potencjalne podatności i opisuje ich charakter,
  • ocenia poziom pewności wykrycia oraz wagę problemu,
  • wskazuje sposób odtworzenia błędu,
  • generuje zalecenia naprawcze ukierunkowane na konkretną poprawkę,
  • wspiera skany cykliczne i integracje z istniejącymi platformami bezpieczeństwa.

Kontekst / historia

Premiera Claude Security wpisuje się w szerszy trend obserwowany na rynku: modele AI coraz skuteczniej wspierają nie tylko obronę, ale również działania ofensywne. W praktyce oznacza to, że narzędzia wykorzystujące duże modele językowe mogą przyspieszać analizę podatności, ułatwiać zrozumienie złożonych błędów programistycznych i skracać czas potrzebny do przygotowania technik eksploatacji.

Z perspektywy organizacji problem polega na tym, że tradycyjny model obsługi podatności bywa zbyt wolny. Ręczna analiza, przekazanie ustaleń do deweloperów, iteracyjne poprawki i ponowna weryfikacja często zajmują więcej czasu, niż pozwala na to obecne tempo zagrożeń. Anthropic pozycjonuje więc Claude Security jako narzędzie, które ma pomóc zespołom AppSec i DevSecOps nadążyć za nową dynamiką ryzyka.

Analiza techniczna

Z technicznego punktu widzenia Claude Security pełni rolę wyspecjalizowanego asystenta do analizy bezpieczeństwa kodu źródłowego. Rozwiązanie współpracuje z modelem Claude Opus 4.7 i ma być dostępne bezpośrednio z poziomu interfejsu Claude. Użytkownik wskazuje repozytorium, katalog lub konkretną gałąź, a następnie uruchamia skan w poszukiwaniu potencjalnych problemów bezpieczeństwa.

Istotną cechą rozwiązania jest nacisk na użyteczność operacyjną. Narzędzie ma nie tylko sygnalizować możliwe błędy, ale także tłumaczyć ich znaczenie, określać poziom pewności i podpowiadać sposób reprodukcji. To ważne, ponieważ w praktyce samo wygenerowanie alertu rzadko wystarcza — zespoły potrzebują kontekstu, który pozwala szybko ocenić, czy dany problem rzeczywiście wymaga natychmiastowej reakcji.

Anthropic podkreśla również ograniczanie liczby false positives. W środowiskach enterprise to jeden z najważniejszych parametrów skuteczności, ponieważ nadmiar błędnych alarmów zwiększa koszty triage i obniża zaufanie do automatyzacji. Jeśli deklarowana dokładność okaże się wysoka, Claude Security może skrócić drogę od detekcji do naprawy z wielu dni do znacznie krótszego cyklu roboczego.

Ważnym elementem są także skany cykliczne, które wpisują się w model ciągłego monitorowania bezpieczeństwa kodu. Takie podejście lepiej odpowiada realiom nowoczesnych pipeline’ów CI/CD, gdzie każda zmiana w kodzie może wprowadzać nowe ryzyko i powinna być możliwie szybko oceniona pod kątem bezpieczeństwa.

Konsekwencje / ryzyko

Uruchomienie Claude Security pokazuje, że AI staje się jednocześnie narzędziem wspierającym obrońców i mnożnikiem efektywności dla atakujących. Dla organizacji oznacza to konieczność skracania czasu reakcji, lepszej priorytetyzacji podatności i większej dyscypliny w obszarze zarządzania poprawkami.

Jednocześnie wdrażanie podobnych rozwiązań wiąże się z ryzykiem nadmiernego zaufania do automatyzacji. Nawet bardzo zaawansowany model może błędnie ocenić kontekst biznesowy, rzeczywistą ekspozycję usługi albo warunki niezbędne do wykorzystania podatności. Z tego powodu wyniki AI powinny wspierać ekspertów, a nie całkowicie zastępować ich ocenę.

Nie można też pominąć kwestii ochrony kodu źródłowego i ładu danych. Organizacje muszą wiedzieć, które repozytoria są analizowane, jakie dane trafiają do systemu, jak wygląda kontrola dostępu oraz czy rozwiązanie spełnia wymagania wewnętrznych polityk bezpieczeństwa i zgodności regulacyjnej.

Rekomendacje

Firmy rozważające wykorzystanie narzędzi takich jak Claude Security powinny podchodzić do wdrożenia etapowo i procesowo, a nie wyłącznie produktowo.

  • Zintegruj narzędzie z istniejącym SDLC i DevSecOps — wyniki analizy powinny trafiać do obecnych procesów triage, backlogu i zarządzania podatnościami.
  • Przeprowadź pilotaż na własnym kodzie — porównanie wyników z ustaleniami zespołu AppSec i klasycznymi testami pozwoli ocenić realną wartość rozwiązania.
  • Określ zasady obsługi false positives i false negatives — bez tego nawet dobre narzędzie może stać się źródłem chaosu operacyjnego.
  • Włącz skany cykliczne dla krytycznych repozytoriów — regularność analizy ma większe znaczenie niż jednorazowy audyt.
  • Zadbaj o governance danych — należy jasno zdefiniować zakres analizowanego kodu, uprawnienia użytkowników i ścieżki audytu.
  • Utrzymaj ekspercką weryfikację — decyzje o priorytetyzacji, akceptacji ryzyka i wdrożeniu poprawek powinny pozostawać pod kontrolą specjalistów.

Podsumowanie

Claude Security jest odpowiedzią na nową fazę wyścigu pomiędzy atakiem a obroną, w której sztuczna inteligencja istotnie skraca czas potrzebny do analizy i eksploatacji podatności. Anthropic chce dzięki temu pomóc zespołom bezpieczeństwa szybciej wykrywać luki, lepiej rozumieć ich znaczenie i sprawniej przygotowywać poprawki.

Najważniejszy wniosek wykracza jednak poza samą premierę produktu. Organizacje powinny zakładać, że AI będzie stale przyspieszać zarówno działania defensywne, jak i ofensywne. Przewagę uzyskają te podmioty, które połączą automatyzację analizy kodu z dojrzałym zarządzaniem podatnościami, kontrolą jakości alertów i silnym nadzorem operacyjnym.

Źródła

  1. SecurityWeek — Anthropic Unveils Claude Security to Counter AI-Powered Exploit Surge — https://www.securityweek.com/anthropic-unveils-claude-security-to-counter-ai-powered-exploit-surge/
  2. Anthropic Blog — Claude Security — https://claude.com/

Atak „Mini Shai-Hulud” na pakiety SAP npm zwiększa ryzyko dla łańcucha dostaw oprogramowania

Cybersecurity news

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania coraz częściej wykorzystują zaufane repozytoria pakietów jako punkt wejścia do środowisk deweloperskich oraz pipeline’ów CI/CD. Incydent określany jako „Mini Shai-Hulud” dotknął pakiety npm powiązane z ekosystemem SAP, w tym narzędzia używane do budowy i wdrażania aplikacji chmurowych. To szczególnie groźne, ponieważ kompromitacja zależności uruchamianych automatycznie podczas instalacji może prowadzić do przejęcia sekretów, tokenów publikacyjnych oraz poświadczeń chmurowych.

W skrócie

Kampania „Mini Shai-Hulud” objęła cztery pakiety npm powiązane z SAP: @cap-js/sqlite w wersji 2.2.2, @cap-js/postgres w wersji 2.2.2, @cap-js/db-service w wersji 2.10.1 oraz mbt w wersji 1.2.48. Złośliwe wersje zawierały skrypty preinstall, które uruchamiały wieloetapowy ładunek przeznaczony do kradzieży sekretów z systemów deweloperskich i środowisk CI/CD.

  • Celem były m.in. tokeny GitHub i npm.
  • Atakujący szukali również poświadczeń dostawców chmurowych i sekretów Kubernetes.
  • Złośliwe pakiety mogły ułatwiać dalszą propagację poprzez przejęte dane publikacyjne i dostępowe.
  • Choć pakiety zostały wycofane po wykryciu, ryzyko dla organizacji pozostaje istotne.

Kontekst / historia

Incydent wpisuje się w szerszy trend operacji software supply chain, w których przestępcy nie atakują bezpośrednio organizacji końcowej, lecz kompromitują zaufane komponenty używane przez deweloperów. Badacze powiązali kampanię z grupą TeamPCP na podstawie podobieństw technicznych i operacyjnych do wcześniejszych incydentów dotyczących projektów open source.

Nazwa „Mini Shai-Hulud” nawiązuje do wcześniejszych kampanii „Shai-Hulud”, które od 2025 roku były kojarzone z robakopodobnym rozprzestrzenianiem się przez ekosystemy pakietów. W tym przypadku skala publikacji była mniejsza, ale wybrane cele miały znacznie wyższą wartość operacyjną. Atak skoncentrował się na pakietach istotnych dla środowisk enterprise oraz procesów wdrożeniowych SAP, co zwiększa potencjalny wpływ biznesowy.

Analiza techniczna

Technicznie atak polegał na wstrzyknięciu złośliwych skryptów preinstall do opublikowanych pakietów npm. To szczególnie niebezpieczny mechanizm, ponieważ kod wykonuje się automatycznie już na etapie instalacji zależności, zanim aplikacja zostanie uruchomiona lub poddana testom. W praktyce oznacza to, że samo pobranie zainfekowanego pakietu mogło uruchomić łańcuch infekcji na stacji deweloperskiej albo w runnerze CI.

Ładunek był wieloetapowy i zaciemniony. Jego zadaniem było wyszukiwanie oraz eksfiltracja sekretów z wielu źródeł jednocześnie. Obejmowało to tokeny GitHub, dane npm, poświadczenia do głównych platform chmurowych, sekrety pipeline’ów CI/CD oraz artefakty lokalnych narzędzi deweloperskich. Z analiz wynika, że celem nie była wyłącznie kradzież danych, ale również dalsza propagacja z użyciem przejętych tokenów publikacyjnych i dostępowych.

Znaczenie ma także charakter zaatakowanych pakietów. Komponenty CAP są wykorzystywane w SAP Cloud Application Programming Model, natomiast mbt służy do budowania archiwów MTA gotowych do wdrożenia. Oznacza to, że infekcja mogła występować dokładnie w tym miejscu procesu, gdzie spotykają się kod aplikacji, sekrety wdrożeniowe, dostęp do repozytoriów oraz mechanizmy publikacji. Z perspektywy obrońcy jest to scenariusz szczególnie trudny, bo atak uderza bezpośrednio w warstwę zaufania między deweloperem, systemem budowania i platformą chmurową.

Badacze wskazali również na podobieństwa do wcześniejszych kampanii przypisywanych TeamPCP, w tym zbieżność metod eksfiltracji i wykorzystania przejętych danych do dalszego rozszerzania kompromitacji. Pojawiła się też hipoteza, że początkowy dostęp mógł mieć związek z niewłaściwie zabezpieczonym tokenem npm ujawnionym w procesach pull request build, co ponownie podkreśla znaczenie ochrony sekretów w automatyzacji CI/CD.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem tego typu incydentu nie jest samo uruchomienie złośliwego kodu, lecz przejęcie zaufanych poświadczeń umożliwiających dalsze ataki. Jeśli zainfekowany pakiet został zainstalowany w środowisku deweloperskim lub pipeline’ie, atakujący mogli uzyskać dostęp do repozytoriów kodu, kont publikacyjnych, środowisk chmurowych, klastrów Kubernetes oraz systemów wdrożeniowych.

Ryzyko dla organizacji korzystających z narzędzi SAP jest ponadprzeciętne, ponieważ dotknięte pakiety znajdują się blisko procesu budowy i dostarczania aplikacji biznesowych. W praktyce może to oznaczać:

  • wyciek sekretów i danych dostępnych dla procesów build/deploy,
  • nieautoryzowane publikacje kolejnych pakietów lub modyfikacje repozytoriów,
  • kompromitację środowisk klientów końcowych w modelu downstream,
  • utratę integralności pipeline’ów oraz artefaktów wdrożeniowych,
  • długotrwałą obecność atakującego dzięki przejętym tokenom i kluczom.

Dodatkowym problemem jest opóźniona wykrywalność. Nawet jeśli złośliwe wersje zostały usunięte, organizacje muszą zakładać, że każde środowisko, które je pobrało, mogło zostać już skażone. W takim scenariuszu samo usunięcie pakietu nie rozwiązuje problemu, ponieważ przejęte sekrety mogły zostać użyte do dalszej kompromitacji.

Rekomendacje

Organizacje powinny potraktować incydent jako sygnał do natychmiastowego przeglądu bezpieczeństwa software supply chain. Kluczowe działania obejmują:

  • Identyfikację narażenia — przeszukanie lockfile, cache’y pakietów, logów CI/CD, rejestrów wewnętrznych i stacji deweloperskich pod kątem zainfekowanych wersji oraz weryfikację, czy wskazane wersje były pobierane lub instalowane w czasie incydentu.
  • Rotację sekretów — natychmiastową zmianę tokenów npm i GitHub, a także rotację poświadczeń chmurowych, sekretów CI/CD, danych dostępowych Kubernetes i innych kluczy obecnych w środowisku build.
  • Analizę integralności repozytoriów — sprawdzenie historii commitów, workflow automation oraz konfiguracji publikacji pakietów, aby ustalić, czy doszło do nieautoryzowanych zmian.
  • Wzmocnienie kontroli łańcucha dostaw — stosowanie wewnętrznych mirrorów, repozytoriów pośredniczących i polityk zatwierdzania zależności oraz skanowanie pakietów pod kątem złośliwych hooków instalacyjnych.
  • Ograniczenie uprawnień — wdrożenie krótkotrwałych tokenów, zasady najmniejszych uprawnień oraz separacji środowisk deweloperskich od produkcyjnych.
  • Monitoring i detekcję — obserwowanie nietypowych publikacji pakietów, zmian w workflow CI oraz połączeń wychodzących z runnerów build.

Podsumowanie

„Mini Shai-Hulud” pokazuje, że współczesne ataki na łańcuch dostaw są coraz bardziej precyzyjne i ukierunkowane na komponenty o wysokiej wartości operacyjnej. W tym przypadku kompromitacja objęła pakiety SAP npm używane w procesach tworzenia i wdrażania aplikacji chmurowych, co zwiększa potencjalny wpływ na środowiska enterprise. Największe zagrożenie wynika z możliwości kradzieży sekretów i przejęcia zaufanych mechanizmów publikacji oraz CI/CD. Dla zespołów bezpieczeństwa i DevSecOps to kolejny dowód, że ochrona zależności, tokenów publikacyjnych i pipeline’ów musi być traktowana jako element krytyczny, a nie wyłącznie operacyjny.

Źródła

  1. Dark Reading — TeamPCP Hits SAP Packages With 'Mini Shai-Hulud’ Attack — https://www.darkreading.com/cloud-security/teampcp-sap-packages-mini-shai-hulud
  2. Endor Labs — Mini Shai-Hulud: npm Worm Hits SAP Developer Packages — https://www.endorlabs.com/learn/mini-shai-hulud-npm-worm-hits-sap-developer-packages
  3. SAP Security Notes & News — https://support.sap.com/en/my-support/knowledge-base/security-notes-news.html
  4. Upwind — Mini Shai-Hulud Targets SAP npm Packages — https://www.upwind.io/feed/mini-shai-hulud-targets-sap-npm-packages-ci-cd-publishing-pipeline-abused-in-supply-chain-attack
  5. Layer Seven Security — Mini Shai-Hulud: Malware Targeting the Software Supply Chain for SAP Development Tools — https://www.layersevensecurity.com/mini-shai-hulud-malware-targeting-the-software-supply-chain-for-sap-development-tools/

Zatrute pakiety RubyGems i moduły Go atakują pipeline’y CI/CD i wykradają poświadczenia

Cybersecurity news

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania coraz częściej obejmują nie tylko stacje robocze programistów, ale również środowiska automatyzacji budowania i wdrażania. Najnowsza kampania pokazuje, że złośliwe pakiety publikowane w ekosystemach RubyGems i Go mogą służyć jako nośnik do kradzieży sekretów, manipulowania procesem buildów oraz utrwalania dostępu do przejętych hostów.

To szczególnie groźny scenariusz dla organizacji korzystających z CI/CD, GitHub Actions oraz środowisk DevSecOps, gdzie pojedyncza zależność może uzyskać dostęp do tokenów, kluczy i konfiguracji używanych w całym cyklu dostarczania oprogramowania.

W skrócie

  • Kampania została powiązana z kontem BufferZoneCorp publikującym złośliwe biblioteki podszywające się pod znane pakiety Ruby i Go.
  • Część pakietów działała jako sleeper packages, czyli pozornie niegroźne komponenty wykorzystywane na dalszym etapie ataku.
  • Złośliwe gemy Ruby wykradały sekrety już podczas instalacji.
  • Moduły Go ingerowały w środowiska GitHub Actions, podmieniały mechanizmy uruchamiania narzędzi i mogły zapewniać trwały dostęp przez SSH.
  • Nawet jeśli pakiety zostały już usunięte z rejestrów, samo ich pobranie mogło oznaczać incydent bezpieczeństwa.

Kontekst / historia

Ataki typu software supply chain z wykorzystaniem publicznych rejestrów pakietów nie są nowym zjawiskiem, jednak obserwowany poziom ich dojrzałości operacyjnej stale rośnie. Wcześniej dominowały kampanie oparte na typosquattingu, dependency confusion lub prostych bibliotekach kradnących zmienne środowiskowe.

W tym przypadku atakujący zastosowali bardziej zaawansowany model działania. Pakiety imitowały rozpoznawalne nazwy bibliotek używanych w codziennej pracy programistów i administratorów, a kampania była rozproszona pomiędzy dwa popularne ekosystemy: Ruby oraz Go. To zwiększało szansę na skuteczne trafienie zarówno w aplikacje backendowe, jak i w narzędzia infrastrukturalne oraz komponenty wykonywane automatycznie przez pipeline’y.

W praktyce oznacza to przejście od prostego wykradania danych do prób przejmowania kontroli nad procesem wytwarzania oprogramowania. To właśnie dlatego środowiska CI/CD stają się dziś jednym z najważniejszych celów nowoczesnych operacji supply chain.

Analiza techniczna

W przypadku złośliwych gemów Ruby kluczowym momentem była sama instalacja pakietu. Ładunek uruchamiał się jeszcze przed uruchomieniem aplikacji i wyszukiwał dane wrażliwe obecne na hostach deweloperskich lub runnerach CI. Celem były między innymi zmienne środowiskowe, klucze SSH, sekrety AWS, pliki konfiguracyjne takie jak .npmrc i .netrc, ustawienia GitHub CLI oraz poświadczenia RubyGems.

Po zebraniu informacji następowała ich eksfiltracja do infrastruktury kontrolowanej przez operatora kampanii. Taki model ataku jest wyjątkowo niebezpieczny, ponieważ nie wymaga uruchomienia aplikacji produkcyjnej. Wystarczy samo pobranie lub instalacja zależności, aby aktywować mechanizm kradzieży.

Złośliwe moduły Go działały bardziej wieloetapowo. Według opublikowanych analiz nie wszystkie zawierały identyczny payload, ale razem tworzyły funkcjonalny zestaw narzędzi do naruszenia integralności pipeline’u. Jednym z najgroźniejszych elementów była ingerencja w środowisko GitHub Actions. Moduł wykrywał mechanizmy związane z workflow, ustawiał zmienne proxy i zapisywał fałszywy wrapper dla polecenia go w katalogu cache.

Następnie atakujący doprowadzał do zmiany ścieżki wykonywania, aby podstawiony wrapper był uruchamiany przed prawdziwym binarium. Dzięki temu możliwe było przechwytywanie lub modyfikowanie kolejnych wywołań narzędzia go, przy jednoczesnym przekazaniu sterowania do legalnego pliku wykonywalnego. Taka technika utrudnia wykrycie, ponieważ build może zakończyć się pozornie prawidłowo.

Dodatkowo część modułów była zdolna do utrwalania dostępu przez dopisanie zakodowanego na stałe klucza publicznego do pliku ~/.ssh/authorized_keys. To klasyczny mechanizm persistence, umożliwiający powrót na przejęty host bez potrzeby ponownego używania skradzionych haseł lub tokenów.

Na uwagę zasługuje także użycie sleeper packages. Takie pakiety mogą przez dłuższy czas nie wykazywać jednoznacznie złośliwego zachowania, a ich właściwa funkcja ujawnia się dopiero w dalszej fazie kampanii. To znacząco utrudnia wykrywanie oparte wyłącznie na reputacji pakietu, nazwie lub szybkiej analizie metadanych.

Konsekwencje / ryzyko

Skala ryzyka wynikającego z tej kampanii jest wysoka, ponieważ zagrożone są jednocześnie trzy kluczowe obszary: poufność sekretów, integralność procesu buildów oraz kontrola nad hostami wykonawczymi.

Wyciek zmiennych środowiskowych i plików konfiguracyjnych może prowadzić do przejęcia kont chmurowych, repozytoriów kodu, rejestrów pakietów, systemów CI i innych usług zintegrowanych z cyklem wytwórczym. Manipulacja workflow oraz podmiana wrapperów binarnych tworzy z kolei ryzyko cichego skażenia artefaktów, wstrzyknięcia dodatkowego kodu lub naruszenia integralności całego procesu release management.

Najpoważniejszy scenariusz obejmuje trwałą kompromitację runnera, serwera buildowego lub stacji deweloperskiej. Jeśli na hoście pojawi się nieautoryzowany wpis w authorized_keys, incydent nie kończy się na jednorazowej eksfiltracji sekretów, lecz może przerodzić się w długotrwały dostęp atakującego i dalszy ruch boczny w infrastrukturze.

W organizacjach korzystających z self-hosted runnerów skutki mogą być jeszcze poważniejsze, ponieważ naruszenie takiego środowiska bywa trudniejsze do zauważenia niż kompromitacja efemerycznych instancji uruchamianych jednorazowo.

Rekomendacje

Organizacje, które mogły pobrać wskazane pakiety, powinny traktować sprawę jako potencjalny incydent bezpieczeństwa. Sama eliminacja podejrzanej zależności nie wystarczy, jeśli doszło już do kradzieży danych uwierzytelniających lub utrwalenia dostępu.

  • Zweryfikować, czy podejrzane pakiety występowały w plikach Gemfile, gemspec, go.mod, cache zależności, artefaktach buildów i logach pipeline’ów.
  • Usunąć złośliwe komponenty z projektów oraz środowisk wykonawczych.
  • Przeanalizować logi pod kątem nietypowych połączeń wychodzących HTTPS oraz dostępu do wrażliwych plików podczas instalacji pakietów.
  • Przeprowadzić pełną rotację narażonych sekretów, w tym kluczy SSH, tokenów GitHub, poświadczeń AWS i danych do rejestrów pakietów.
  • Skontrolować plik ~/.ssh/authorized_keys na hostach deweloperskich, runnerach i serwerach buildowych pod kątem nieautoryzowanych wpisów.
  • Ograniczyć zakres sekretów dostępnych w jobach CI zgodnie z zasadą najmniejszych uprawnień.
  • Stosować efemeryczne runnery wszędzie tam, gdzie jest to możliwe.
  • Wymuszać pinowanie wersji zależności i przegląd nowych pakietów przed dopuszczeniem ich do buildów.
  • Monitorować zmiany w PATH, pojawianie się wrapperów narzędzi w katalogach cache oraz modyfikacje plików SSH.
  • Blokować nieautoryzowane połączenia wychodzące z pipeline’ów i segmentować środowiska build od produkcji.

Warto również wdrożyć mechanizmy wykrywania anomalii w procesie budowania, obejmujące nietypowe operacje na konfiguracjach, tworzenie dodatkowych binariów pomocniczych i odwołania do rzadko obserwowanych domen lub webhooków.

Podsumowanie

Opisana kampania pokazuje, że nowoczesne ataki na łańcuch dostaw oprogramowania są projektowane z myślą o realnych workflow deweloperskich i środowiskach CI/CD. Złośliwa zależność nie musi już jedynie kraść pojedynczych zmiennych środowiskowych — może ingerować w pipeline, przejmować wykonanie narzędzi, utrwalać dostęp do hosta i wpływać na integralność finalnych artefaktów.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona rejestrów zależności, runnerów CI oraz procesów budowania powinna być traktowana jako kluczowy element bezpieczeństwa całego cyklu życia oprogramowania.

Źródła

  1. Poisoned Ruby Gems and Go Modules Exploit CI Pipelines for Credential Theft — https://thehackernews.com/2026/05/poisoned-ruby-gems-and-go-modules.html
  2. Socket Ecosystem Support — https://docs.socket.dev/docs/language-support
  3. Introducing Ruby Support in Socket — https://socket.dev/blog/introducing-ruby
  4. Go Support Is Now Generally Available — https://socket.dev/blog/go-support-is-now-generally-available

Złośliwa zależność npm powiązana z commitami wspieranymi przez AI atakuje portfele kryptowalut

Cybersecurity news

Wprowadzenie do problemu / definicja

Ekosystem npm pozostaje jednym z najczęściej atakowanych elementów łańcucha dostaw oprogramowania. Najnowszy incydent pokazuje, że zagrożenie nie ogranicza się już wyłącznie do klasycznych kampanii typosquattingowych czy przejęć kont maintainerów. Coraz częściej atakujący wykorzystują także workflow deweloperski oparty na narzędziach AI, aby przemycić złośliwe zależności do projektu i uzyskać dostęp do danych wrażliwych, w tym sekretów środowiskowych oraz portfeli kryptowalut.

W skrócie

W opisywanym przypadku wykryto złośliwą zależność npm, która została powiązana z commitem przygotowanym lub wspieranym przez narzędzie AI. Pakiet miał za zadanie pozyskiwać wrażliwe informacje z systemu ofiary, a jednym z głównych celów były dane związane z portfelami kryptowalut. Incydent wpisuje się w rosnący trend ataków na software supply chain, w których punkt wejścia stanowią nie tylko bezpośrednio instalowane biblioteki, ale również zależności pośrednie i automatyczne sugestie generowane przez asystentów programistycznych.

Kontekst / historia

Ataki na rejestry pakietów open source od lat są skuteczną metodą kompromitacji środowisk deweloperskich. W przeszłości dominowały kampanie polegające na publikowaniu pakietów o nazwach łudząco podobnych do legalnych bibliotek, ukrywaniu złośliwego kodu w skryptach instalacyjnych lub podmienianiu wersji zależności używanych przez szerokie grono projektów.

Nowy element tego krajobrazu stanowi wykorzystanie AI w procesie tworzenia i modyfikowania kodu. Narzędzia wspierające programistów potrafią generować fragmenty aplikacji, proponować biblioteki, a nawet automatyzować commity i aktualizacje zależności. Jeśli taki proces nie jest objęty rygorystyczną kontrolą, zwiększa się ryzyko nieświadomego zaakceptowania komponentu, który formalnie wygląda poprawnie, ale zawiera złośliwą logikę. To szczególnie niebezpieczne w zespołach o wysokim tempie pracy, gdzie presja na szybkie wdrożenie zmian ogranicza manualną weryfikację diffów i lockfile.

Analiza techniczna

Z technicznego punktu widzenia zagrożenie wpisuje się w model ataku na łańcuch dostaw poprzez zależność aplikacyjną. Złośliwy pakiet po zainstalowaniu w środowisku Node.js może wykonywać kod na etapie instalacji, uruchomienia aplikacji albo podczas importu modułu. Tego typu komponenty są często projektowane tak, aby wyglądały jak nieszkodliwe biblioteki pomocnicze, a jednocześnie uruchamiały mechanizmy kradzieży danych w tle.

W analizowanym scenariuszu celem były przede wszystkim informacje pozwalające na przejęcie aktywów kryptowalutowych. Obejmuje to między innymi:

  • pliki konfiguracyjne portfeli,
  • seed phrase i klucze prywatne zapisane lokalnie,
  • tokeny dostępu i zmienne środowiskowe,
  • dane uwierzytelniające przechowywane w katalogach użytkownika,
  • sekrety używane przez narzędzia deweloperskie i CI/CD.

Szczególnie istotny jest aspekt powiązania z commitem wspieranym przez AI. Nie oznacza to automatycznie, że samo narzędzie AI było źródłem ataku, ale wskazuje na ryzyko, że wygenerowana sugestia kodu lub zależności została zaakceptowana bez wystarczającej walidacji. Atakujący mogą wykorzystywać fakt, że asystenci kodowania przyspieszają pracę, lecz nie gwarantują poprawnej oceny reputacji pakietu, integralności maintainerów ani bezpieczeństwa zależności pośrednich.

Praktyczny łańcuch ataku może wyglądać następująco:

  • Deweloper lub agent AI dodaje nową zależność do projektu.
  • Menedżer pakietów pobiera bibliotekę bez pełnej analizy jej historii i reputacji.
  • Złośliwy kod uruchamia się podczas instalacji lub pierwszego użycia modułu.
  • Malware przeszukuje system pod kątem portfeli, sekretów i plików konfiguracyjnych.
  • Zebrane dane są wysyłane do infrastruktury kontrolowanej przez napastnika.
  • Atakujący wykorzystuje pozyskane informacje do kradzieży środków lub dalszej kompromitacji organizacji.

Konsekwencje / ryzyko

Ryzyko operacyjne takiego incydentu jest wysokie, ponieważ obejmuje zarówno warstwę developerską, jak i biznesową. W najprostszym scenariuszu skutkiem jest utrata środków kryptowalutowych należących do użytkownika lub organizacji. W bardziej zaawansowanych przypadkach konsekwencje mogą objąć także:

  • wyciek sekretów do systemów chmurowych,
  • przejęcie kont deweloperskich,
  • kompromitację pipeline’ów CI/CD,
  • podmianę artefaktów buildów,
  • propagację złośliwego kodu do środowisk produkcyjnych,
  • naruszenie poufności kodu źródłowego i danych klientów.

Największe zagrożenie dotyczy organizacji, które dopuszczają automatyczne dodawanie zależności przez narzędzia AI bez polityk zatwierdzania. W takim modelu pojedyncza błędna sugestia może doprowadzić do pełnej kompromitacji stacji roboczej dewelopera, a następnie do lateral movement w kierunku repozytoriów, systemów buildowych i zasobów chmurowych.

Rekomendacje

Organizacje rozwijające oprogramowanie w ekosystemie JavaScript powinny potraktować ten incydent jako sygnał do wzmocnienia kontroli nad zależnościami i użyciem AI w SDLC. Kluczowe działania obejmują:

  • wymuszenie ręcznego przeglądu każdej nowej zależności dodawanej do projektu,
  • analizę diffów w plikach package.json oraz lockfile przed akceptacją merge requestów,
  • blokowanie automatycznego wykonywania niezweryfikowanych skryptów instalacyjnych,
  • stosowanie wewnętrznych proxy lub mirrorów rejestrów pakietów,
  • wdrożenie skanerów SCA oraz reguł wykrywających podejrzane zachowania pakietów,
  • monitorowanie dostępu do plików portfeli, katalogów domowych i zmiennych środowiskowych,
  • segmentację środowisk deweloperskich oraz ograniczenie lokalnego przechowywania kluczy,
  • używanie menedżerów sekretów zamiast przechowywania danych w plikach konfiguracyjnych,
  • egzekwowanie zasady least privilege dla tokenów npm, Git i chmury,
  • objęcie narzędzi AI polityką bezpieczeństwa, audytem oraz kontrolą uprawnień.

Dodatkowo warto wdrożyć zasady dotyczące bezpiecznego użycia asystentów kodowania:

  • AI nie powinno samodzielnie zatwierdzać zmian w zależnościach,
  • każda sugestia biblioteki powinna być oceniana pod kątem reputacji, popularności i historii publikacji,
  • zespół powinien prowadzić ewidencję pakietów dopuszczonych do użycia,
  • podejrzane lub nowe biblioteki należy uruchamiać najpierw w odizolowanym środowisku testowym.

W przypadku podejrzenia kompromitacji należy niezwłocznie usunąć katalogi zależności, odtworzyć środowisko z zaufanych źródeł, zrotować wszystkie sekrety oraz przeprowadzić analizę forensic pod kątem exfiltracji danych i obecności dodatkowych mechanizmów persistence.

Podsumowanie

Incydent ze złośliwą zależnością npm ukierunkowaną na portfele kryptowalut potwierdza, że software supply chain pozostaje jednym z kluczowych obszarów ryzyka w nowoczesnym SDLC. Nowością nie jest sam fakt użycia złośliwego pakietu, lecz rosnące znaczenie AI jako elementu workflow, który może przyspieszać zarówno rozwój oprogramowania, jak i błędne decyzje bezpieczeństwa. Dla zespołów DevSecOps oznacza to konieczność rozszerzenia klasycznych mechanizmów ochrony zależności o kontrolę procesów, w których sugestie generowane przez AI wpływają na skład projektu. Bez takiego podejścia nawet pozornie niewielka zmiana w drzewie zależności może przełożyć się na pełnoskalowy incydent bezpieczeństwa.

Źródła

  1. Malicious npm Dependency Linked to AI Assisted Commit Targets Crypto Wallets — https://www.infosecurity-magazine.com/news/ai-npm-dependency-targets-crypto/
  2. Open Source Community Thwarts Massive npm Supply Chain Attack — https://www.infosecurity-magazine.com/news/npm-supply-chain-attack-averted/
  3. New NPM Worm Hijacks CI Workflows, Targets AI Packages — https://www.ox.security/blog/npm-worm-hijacks-ci-workflows-ai-packages/

Krytyczna podatność LangChain Core umożliwia SSTI i zdalne wykonanie kodu

Cybersecurity news

Wprowadzenie do problemu / definicja

W ekosystemie aplikacji opartych na modelach językowych bezpieczeństwo warstwy pomocniczej, w tym mechanizmów serializacji i deserializacji, ma bezpośredni wpływ na odporność całego środowiska. Opisana podatność w LangChain Core dotyczy niebezpiecznej deserializacji danych wejściowych, która może prowadzić do Server-Side Template Injection (SSTI), a następnie do zdalnego wykonania kodu (RCE).

Problem pojawia się wtedy, gdy dane kontrolowane przez użytkownika są błędnie interpretowane jako zaufane obiekty frameworka. W praktyce umożliwia to odtworzenie niebezpiecznych struktur aplikacyjnych i uruchomienie złośliwej logiki po stronie serwera.

W skrócie

Podatność została opisana jako CVE-2025-68664 i dotyczy wersji LangChain oraz LangChain Core wcześniejszych niż 0.3.81 oraz 1.2.5. Źródłem problemu jest obsługa słownika zawierającego specjalny klucz wykorzystywany przez framework do oznaczania serializowanych obiektów.

  • możliwa jest deserializacja kontrolowanych danych do obiektu PromptTemplate,
  • atak wykorzystuje format jinja2,
  • skutkiem może być SSTI,
  • w dalszej fazie ataku możliwe jest wykonanie poleceń systemowych.

Z perspektywy bezpieczeństwa jest to podatność o bardzo wysokim znaczeniu, szczególnie w środowiskach przetwarzających niezaufane dane, zapisane workflow lub współdzielone obiekty między usługami.

Kontekst / historia

LangChain jest szeroko wykorzystywany do budowy agentów, łańcuchów przetwarzania oraz aplikacji integrujących modele językowe z bazami danych, usługami zewnętrznymi i narzędziami automatyzacji. Wraz ze wzrostem popularności tych rozwiązań rośnie również powierzchnia ataku związana z promptami, parserami, pamięcią konwersacyjną i formatami serializacji.

W tym przypadku problem nie wynika z pojedynczej wady samego silnika szablonów, ale z całego łańcucha zdarzeń: błędnej serializacji, niebezpiecznej deserializacji i późniejszego renderowania treści szablonu. To ważne, ponieważ wiele organizacji koncentruje się na ochronie promptów, pomijając bezpieczeństwo transportu i przechowywania obiektów aplikacyjnych.

Podatność została zaadresowana w poprawionych wydaniach bibliotek. Zagrożenie pozostaje jednak istotne dla organizacji utrzymujących starsze wersje, własne forki kodu oraz integracje korzystające z danych pochodzących z niezweryfikowanych źródeł.

Analiza techniczna

Techniczny rdzeń podatności dotyczy funkcji serializujących i deserializujących obiekty. Framework wykorzystuje specjalną strukturę identyfikującą własne komponenty. Jeżeli aplikacja dopuszcza serializację dowolnych słowników przekazanych przez użytkownika, a następnie odtwarza je jako struktury LangChain, napastnik może przygotować dane wyglądające jak legalna definicja konstruktora.

W scenariuszu ataku złośliwy ładunek wskazuje na konstrukcję PromptTemplate i definiuje szablon w formacie jinja2. Po deserializacji obiekt zostaje utworzony jako prawidłowy komponent frameworka, a jego późniejsze renderowanie prowadzi do interpretacji treści po stronie serwera.

  • napastnik dostarcza kontrolowany słownik z kluczem rozpoznawanym jako znacznik obiektu frameworka,
  • mechanizm serializacji nie neutralizuje tej struktury,
  • funkcja deserializacji traktuje dane jak zaufany obiekt,
  • tworzony jest obiekt szablonu zawierający niebezpieczny payload,
  • renderowanie szablonu prowadzi do SSTI,
  • SSTI może umożliwić wykonanie poleceń systemowych lub dostęp do danych środowiskowych.

Formalnie jest to przypadek niebezpiecznej deserializacji, jednak praktyczny wpływ wynika z przecięcia kilku warstw logiki aplikacyjnej: formatu obiektów, silnika szablonów i uprawnień procesu uruchomieniowego. W środowiskach produkcyjnych skutkiem może być odczyt sekretów, tokenów API, zmiennych środowiskowych oraz danych konfiguracyjnych.

Konsekwencje / ryzyko

Największe ryzyko dotyczy aplikacji AI, które przyjmują zewnętrzne workflow, zapisują i przywracają obiekty LangChain albo renderują prompty pochodzące z niezaufanych źródeł. Szczególnie niebezpieczne są wdrożenia działające z dostępem do wrażliwych sekretów i szerokich zasobów sieciowych.

  • wyciek kluczy API i tokenów usług LLM,
  • ujawnienie poświadczeń chmurowych i danych klientów,
  • dostęp do informacji konfiguracyjnych środowiska,
  • możliwość dalszego ruchu bocznego w infrastrukturze,
  • zwiększone ryzyko nadużyć w architekturach agentowych.

Ryzyko rośnie także wtedy, gdy organizacja zakłada, że serializowane dane mają charakter wyłącznie wewnętrzny. W praktyce mogą one pochodzić z webhooków, kolejek, integracji SaaS, repozytoriów promptów lub paneli administracyjnych dostępnych dla wielu użytkowników.

Rekomendacje

Podstawowym działaniem naprawczym jest aktualizacja do wersji niezawierających podatności. Organizacje powinny sprawdzić, czy w środowisku nie występują wersje wcześniejsze niż 0.3.81 lub 1.2.5, a następnie przeprowadzić przegląd zależności bezpośrednich i pośrednich.

  • zablokować deserializację niezaufanych danych do obiektów frameworka,
  • traktować zewnętrzne słowniki i konfiguracje jako dane, a nie obiekty wykonywalne,
  • ograniczyć użycie formatów szablonów wysokiego ryzyka tam, gdzie nie są niezbędne,
  • przeanalizować wszystkie miejsca tworzenia i renderowania PromptTemplate,
  • odseparować sekrety od procesu aplikacyjnego i stosować poświadczenia krótkotrwałe,
  • uruchamiać aplikacje LLM z minimalnymi uprawnieniami,
  • monitorować nietypowe renderowanie szablonów i proces ładowania obiektów,
  • wdrożyć reguły detekcyjne pod kątem SSTI i nadużyć mechanizmów deserializacji,
  • przeprowadzić przegląd logów związanych z ładowaniem pipeline’ów, promptów i konfiguracji agentów.

W środowiskach korporacyjnych dobrą praktyką będzie również wykonanie Software Composition Analysis, walidacja SBOM oraz wdrożenie polityk blokujących publikację podatnych wersji bibliotek AI do produkcji.

Podsumowanie

CVE-2025-68664 pokazuje, że bezpieczeństwo aplikacji opartych na LLM nie kończy się na filtrowaniu promptów i ochronie modeli. Krytyczne znaczenie mają również pozornie pomocnicze mechanizmy frameworków, takie jak serializacja i deserializacja.

W tym przypadku połączenie błędnej obsługi specjalnego klucza obiektowego z możliwością utworzenia szablonu Jinja2 prowadzi do scenariusza SSTI/RCE o bardzo wysokim wpływie operacyjnym. Dla zespołów bezpieczeństwa, DevSecOps i właścicieli platform AI oznacza to konieczność pilnej aktualizacji bibliotek, przeglądu przepływów danych oraz ograniczenia zaufania do wszystkich zewnętrznych struktur wejściowych.

Źródła

  1. Exploit Database – LangChain Core 1.2.4 – SSTI/RCE – Multiple webapps Exploit
  2. NVD – CVE-2025-68664
  3. GitHub Security Advisory – GHSA-c67j-w6g6-q2cm
  4. LangChain Release Notes – langchain-core 1.2.5
  5. PyPI – langchain-core package