Najnowszy Krajobraz Zagrożeń prezentuje przede wszystkim ataki na łańcuchy dostaw (m. in. Mini Shai-Hulud) nieustannie pokazujące ich rozległe i niespodziewane skutki. Ponownie pojawia się grupa ShinyHunters tym razem sprzedająca dane firmy Vercel. Nie zabrakło także podatności Copy Fail zachęcającej do odświeżenia procedur inwentaryzacji i aktualizacji systemów Linux w organizacji. 

Łańcuch dostaw

Mini Shai-Hulud i wieloekosystemowy supply chain

• W dniach 29–30 kwietnia 2026 r. Mini Shai-Hulud skompromitował cztery oficjalne pakiety SAP w npm, dwie wersje PyTorch Lightning w PyPI, dwie wersje intercom-client w npm oraz pakiet intercom/intercom-php w Packagist, pokazując zdolność propagacji między trzema ekosystemami pakietów w mniej niż 36 godzin.
• W kampanii wobec SAP złośliwy kod uruchamiał się przez hook preinstall, pobierał runtime Bun i wykonywał silnie zaciemniony payload. Później obserwowano także użycie plików konfiguracyjnych powiązanych z Claude Code i VSCode jako mechanizmu trwałości.
• Kampania została przypisana TeamPCP, opierając się m.in. na wspólnym kluczu RSA i sprawdzeń dla języka rosyjskiego. Wskazano też na 1800 repozytoriów GitHub utworzonych ze skradzionych danych uwierzytelniających.

Jesienią 2025 roku w ekosystemie npm pojawił się Shai-Hulud – robak biorący nazwę od mitycznych piaskowych czerwi z powieści Franka Herberta. Infekował pakiety, kradł tokeny publikacyjne ich właścicieli i używał ich do automatycznego zainfekowania kolejnych paczek dostępnych dla danego tokenu. Mini Shai-Hulud to kolejna fala tej samej rodziny złośliwego oprogramowania, po oryginalnym ataku z września 2025 roku. Tym razem operatorzy udowodnili, że robak potrafi przekroczyć granice pojedynczego ekosystemu.  

SAP 

W pierwszej fazie (29 kwietnia) skompromitowane zostały oficjalne pakiety SAP: mbt@1.2.48, @cap-js/db-service@2.10.1, @cap-js/postgres@2.2.2 oraz @cap-js/sqlite@2.2.2. Łączna tygodniowa liczba pobrań tych pakietów przekraczała 500 000, obejmując SAP Cloud Application Programming Model i narzędzia do budowania SAP Cloud MTA.  

Złośliwe wersje dodały hook uruchamiany automatycznie podczas każdej instalacji pakietu. Jego rolą był bootstraping, w tym przypadku pobranie środowiska uruchomieniowego Bun pobranego z GitHub, a następnie wykonanie silnie zaciemnionego payloadu. Wybór Bun zamiast wbudowanego w system Node.js był celowy – narzędzia monitorujące obserwują procesy potomne Node uruchamiane podczas instalacji pakietów npm, natomiast inny plik binarny omija te mechanizmy. Po zakończeniu pracy payload usuwa po sobie ślady z dysku.  

Zanim złośliwy kod przystąpi do zbierania danych uwierzytelniających, sprawdza czy system jest skonfigurowany dla języka rosyjskiego. W przypadku potwierdzenia payload loguje komunikat „Exiting as russian language detected!” i kończy działanie. To klasyczny wzorzec stosowany przez operatorów z Rosji, aby uniknąć kompromitowania systemów we własnej jurysdykcji.  

Na maszynach deweloperskich payload poszukuje kluczy SSH, danych uwierzytelniających chmurowych dla AWS, Azure i GCP, konfiguracji Kubernetes, tokenów npm i GitHub, plików ze zmiennymi środowiskowymi oraz konfiguracji narzędzi AI. W środowiskach CI/CD uruchamia skrypt odczytujący pamięć procesu runnera bezpośrednio z systemu plików, wydobywając w ten sposób sekrety, które platforma CI stara się maskować w logach. Skradzione dane są szyfrowane i eksfiltrowane do infrastruktury kontrolowanej przez atakujących, a jednocześnie lądują w publicznych repozytoriach GitHub zakładanych na kontach samych ofiar. 

Warto zwrócić uwagę na persistence. Payload umieszcza w każdym dostępnym repozytorium pliki konfiguracyjne, które powodują automatyczne ponowne wykonanie złośliwego kodu przy każdym otwarciu projektu w VSCode lub przy każdym starcie sesji Claude Code.  

Propagacja przez PyPI i Packagist 

30 kwietnia Mini Shai-Hulud objął PyTorch lightning w PyPI (wersje 2.6.2 i 2.6.3, ok. 2,1 miliona tygodniowych pobrań) oraz intercom-client w npm (ok. 300 tysiecy tygodniowych pobrań). OX Security śledziło, jak liczba repozytoriów GitHub ze skradzionymi danymi uwierzytelniającymi rosła z ok. 1200 po fali SAP do 1800.  

Intercom potwierdził, że bezpośrednią przyczyną kompromitacji intercom-client była lokalna instalacja pakietu pyannote-audio, który wprowadził zainfekowany lightning jako zależność tranzytywną. Ten łańcuch połączył atak przez trzy ekosystemy: kompromitacja lightning w PyPI doprowadziła do kompromitacji intercom-client w npm, a ta z kolei do złośliwego artefaktu w Packagist. 

Organizacje, które instalowały skompromitowane wersje pakietów w dniach 29–30 kwietnia, powinny traktować pełną rotację tokenów, kluczy SSH i sekretów CI/CD jako działanie priorytetowe. Konieczny jest również przegląd repozytoriów pod kątem nieautoryzowanych commitów, nowych plików konfiguracyjnych IDE oraz nietypowych hooków instalacyjnych.

Atrybucja: TeamPCP 

Wiz przypisał operację grupie TeamPCP z wysoką pewnością na podstawie lucza publicznego RSA zaobserwowanego także w atakach na Bitwarden CLI i Checkmarx KICS, mechanizmu omijania systemów rosyjskojęzycznych oraz charakterystycznej soli kryptograficznej spójnej z wcześniejszym malwarem TeamPCP. Socket ocenił pewność atrybucji jako średnią, opierając się na tych samych wzorcach kryptograficznych i operacyjnych. 

Patrząc szerzej

Kampania Mini Shai-Hulud zwraca uwagę ze względu na tempo i skalę propagacji. Również istotny jest wątek persistence oparty o konfiguracje narzędzi AI i IDE pokazujący, że zainfekowane repozytorium może stać się źródłem reinfekcji kolejnych środowisk deweloperskich bez dodatkowej interakcji użytkownika. Wraz z rosnącą popularnością agentowych narzędzi programistycznych podobne mechanizmy mogą pojawiać się częściej.

Kampania potwierdza też szerszy trend obserwowany od miesięcy. Skradzione tokeny publikacyjne stały się popularnym narzędziem propagacji malware w ekosystemach open source. Dodatkowe mechanizmy kontroli — takie jak monitoring nowych wersji pakietów czy krótkie okna „cooldown” przed wdrożeniem świeżo opublikowanych wydań — mogą realnie ograniczyć skalę podobnych incydentów. 

Więcej informacji: 
https://www.wiz.io/blog/mini-shai-hulud-supply-chain-sap-npm 
https://socket.dev/blog/sap-cap-npm-packages-supply-chain-attack 
https://www.ox.security/blog/lightning-python-package-shai-hulud-supply-chain-attack/ 
https://socket.dev/blog/mini-shai-hulud-packagist-malicious-intercom-php-package-compromise 

Cybercrime

Od stealera, przez Shadow AI do ataku na łańcuch dostaw 

• Grupa ShinyHunters 19 kwietnia ogłosiła chęć sprzedaży danych firmy Vercel. 
• Vercel zarządza popularnymi bibliotekami Next.js oraz Turbo.js i dostarcza rozwiązania pozwalające na tworzenie aplikacji webowych.
• Firma Vercel potwierdziła incydent i podzieliła się szczegółami, dostęp do ich infrastruktury miał miejsce dzięki poświadczeniom pracownika pozyskanym w ramach incydentu w firmie trzeciej – Context AI.
• Oświadczenia Context AI i Vercel wraz z analizą Hudson Rock tworzą spójny scenariusz wieloetapowego ataku.
• Incydent dotyczy ograniczonej liczby klientów Vercel, którzy zostali poinformowaniu o naruszeniu i jego zakresie, zarządzane przez Vercel paczki npm nie zostały przejęte.

19 kwietnia na jednym z forów przestępczych pojawiło się ogłoszenie o sprzedaży danych firmy Vercel za 2 miliony dolarów. Grupa ShinyHunters sprzedawała zweryfikowane klucze pozwalający na przeprowadzenie, jak to nazwali, potencjalnego globalnego ataku na łańcuch dostaw. Według ogłoszenia oferowany był dostęp do wielu kont pracowników z uprawnieniami do wewnętrznych zasobów firmy oraz klucze API.  

Oświadczenie Vercel 

Tego samego dnia firma Vercel wydała oficjalny komunikat o zaistnieniu incydentu i w kolejnych dniach stopniowo uzupełniała opublikowane informację. Według oświadczenia naruszenie dotyczy ograniczonej liczby klientów i zmiennych środowiskowych, które nie były określone jako wrażliwe. Poszkodowani klienci zostali poinformowani o zdarzeniu.  

We współpracy z GitHub, Microsoft, npm i Socket zespół bezpieczeństwa Vercel potwierdził, że żadna paczka npm publikowana przez Vercel nie została przejęta i zainfekowana. Na ten moment nie ma potwierdzenia, że bezpieczeństwo łańcucha dostaw na poziomie Vercel zostało naruszone. 

Według komunikatu do nieautoryzowanego dostępu do infrastruktury Vercel doszło przy wykorzystaniu skradzionego tokenu OAuth jednego z pracowników służącego do autoryzacji w firmowym Google Workspace. Token pochodził z aplikacji Context AI – firma odnotowała incydent, który skutkował nieautoryzowanym dostępem do takich właśnie poświadczeń. Choć Vercel nie jest klientem Context AI, przynajmniej jeden pracownik skorzystał z tego rozwiązania. 

Incydent w Context AI 

W niedostępnym już na ich stronie oświadczeniu firma Context.ai poinformowała o incydencie dotyczącym ich wycofanej usług AI Office Suite. Zaobserwowano nieautoryzowany dostęp do środowiska AWS związanego z usługą i do zawartych tam poświadczeń użytkowników. Usługa i powiązane z nią zasoby zostały już definitywnie wyłączone – mimo wycofania jej komponenty dalej były aktywne. Narzędzie pozwalało na połączenie agentów AI ze środowiskiem Google Workspace w celu ułatwienia pracy z dokumentami, prezentacjami i arkuszami.   

Pracownik Vercel skorzystał z takiej integracji i umożliwił dostęp do Google Workspace na zasadzie „allow all”. Jeżeli rozwiązanie nie zostało dopuszczone w organizacji, już sama taka integracja powinna wzbudzić alarmy. Jednak dopiero incydent w Context AI sprawił, że potencjalne konsekwencje nadawania aplikacjom wysokich uprawnień stały się rzeczywistością.  

Teoria Hudson Rock 

Choć Context AI nie podzieliło się szczegółami i źródłową przyczyną incydentu, firma Hudson Rock zajmująca się m.in. wyciekami pochodzącymi z infekcji infostelearami publikowała swoją analizę. Odkryli, że około miesiąc przed incydentem wyciekły poświadczenia pracownika Context AI pochodzące z infekcji Lumma Stealerem. Według Hudson Rock, pracownik wyszukiwał exploity do gry Roblox, co jest znanym scenariuszem w przypadku infekcji Lummą. 

Skradzione poświadczenia i dane pozwoliły atakującym na dostęp do wielu zasobów firmy, w tym do konta support@context.ai i środowisk administracyjnych oraz deweloperskich. To z kolei umożliwiło dalszą eskalację uprawnień oraz dostęp do infrastruktury Vercel na podstawie uzyskanego tokenu OAuth. 

Łańcuch ataku przedstawiony przez Hudson Rock opiera się na korelacji pozyskanych przez nich danych z oficjalnymi informacjami o incydencie. Choć nie można ich traktować jak niezaprzeczalnych faktów, oferują interesującą perspektywę na współczesne pozornie trywialne ataki i ich rozległe konsekwencje. Grupy takie jak ShinyHunters znane są z wykorzystywania w atakach dostępów pozyskanych z wycieków.

ShinyHunters 

Grupa od tamtego czasu próbowała wyłudzić okup od innych ofiar, w tym od szkół korzystających z tego samego rozwiązania do zarządzania nauką – Canvas od firmy Instructure. Według samych atakujących incydent dotyczy 9 tysięcy szkół i 275 milionów osób (nauczycieli, uczniów i innych pracowników), których dane osobowe miały znaleźć się wśród skradzionych danych. Instructure potwierdziło, że odnotowali incydent i naruszenie ochrony danych osobowych, lecz nie poinformowali o dokładnej liczbie osób dotkniętych atakiem. 

W zapewnienia ShinyHunters nie powinno się wierzyć bezkrytycznie, lecz należy się spodziewać kolejnych ataków, które pośrednio lub bezpośrednio mogą dotknąć każdego. Skala takich incydentów nie zawsze jest od razu znana. W przypadku powiązań z dostawcą dotkniętym atakiem, konieczne mogą być prewencyjne, szeroko zakrojone działania zabezpieczające. Zaleca się jak zwykle wdrożenie MFA, weryfikację logów pod kątem nieuprawnionych działań, ale także unieważnienie poświadczeń, które mogły wyciec przy okazji incydentu w firmie trzeciej. 

Patrząc szerzej

Zarządzanie ryzykiem związanym z dostawcami, potencjalnymi incydentami oraz podatnościami w dostarczanych przez nich rozwiązaniach znacząco się utrudnia w przypadku Shadow IT i Shadow AI. Nieautoryzowane narzędzia AI (i nie tylko) oraz uwierzytelnianie się do nich za pomocą SSO na podstawie poświadczeń korporacyjnych to przepis na trudny w wykryciu i przeanalizowaniu incydent. Priorytetem powinno być określenie listy dopuszczonych narzędzi i oprogramowania w organizacji oraz ograniczanie dostępu do rozwiązań niedopuszczonych. W opisywanym przypadku widać także potrzebę rzetelnego podejścia do monitoringu wycieków poświadczeń pracowników i odpowiedzialnej reakcji na takie zdarzenia. 

Więcej informacji: 
https://vercel.com/kb/bulletin/vercel-april-2026-security-incident 
https://web.archive.org/web/20260421121735/https://context.ai/security-update  
https://www.infostealers.com/article/breaking-vercel-breach-linked-to-infostealer-infection-at-context-ai/  
https://socradar.io/blog/shinyhunters-breach-instructure-students-teachers/ 

CVE Tygodnia

Copy Fail: lokalna eskalacja uprawnień w jądrze Linux 

• Copy Fail (CVE-2026-31431) umożliwia lokalną eskalację uprawnień do poziomu root na wielu popularnych dystrybucjach Linuxa wydanych po 2017 roku.
• Luka wykorzystuje interakcję między mechanizmami AF_ALG, splice() i komponentem authencesn, pozwalając na modyfikację danych w pamięci podręcznej plików (page cache) bez zmiany pliku na dysku.
• Publicznie dostępny exploit jest niewielki i prosty w użyciu, a ryzyko praktycznej eksploatacji jako wysokie. Kluczowym działaniem ochronnym pozostaje aktualizacja jądra systemu. 

Rzadko zdarza się, by podatność krytyczna wyrosła nie z błędu programistycznego, lecz ze zbiegu niezależnych decyzji projektowych — każda z nich uzasadniona z osobna, razem tworzące okno exploitacji, które przez dziewięć lat było nieodkryte. Podatność CVE-2026-31431, publicznie znana jako Copy Fail, jest właśnie takim przypadkiem. Luka pozwala nieuprzywilejowanemu użytkownikowi na lokalną eskalację uprawnień do poziomu root poprzez wykorzystanie mechanizmów kryptograficznych jądra i sposobu obsługi pamięci podręcznej plików. Problem dotyczy praktycznie wszystkich głównych dystrybucji Linuxa korzystających z jąder wydanych po 2017 roku. 

Kluczową rolę odgrywa tutaj AF_ALG, interfejs umożliwiający aplikacjom użytkownika korzystanie z funkcji kryptograficznych jądra, w połączeniu z mechanizmem splice(), pozwalającym przekazywać dane pomiędzy deskryptorami plików bez ich kopiowania. W określonych warunkach prowadzi to do możliwości wykonania kontrolowanego zapisu do page cache, czyli pamięci podręcznej plików utrzymywanej przez jądro. 

W praktyce oznacza to, że atakujący może zmodyfikować zawartość wykonywalnego pliku znajdującą się w pamięci operacyjnej systemu, bez zmiany samego pliku na dysku. Pokazano to w opublikowanym exploicie, który ma jedynie kilkaset bajtów i wykorzystuje wyłącznie standardowe moduły Pythona. 

Wyróżniającym aspektem Copy Fail jest brak konieczności wykorzystywania wyścigu czasowego (race condition) lub wielokrotnego ponawiania prób. W przeciwieństwie do wcześniejszych podatności, takich jak Dirty Cow czy Dirty Pipe, exploit działa w sposób przewidywalny i stabilny.  

Szczególnie istotne są konsekwencje dla środowisk współdzielonych i kontenerowych. Zagrożone mogą być m.in. klastry Kubernetes, platformy CI/CD, środowiska chmurowe oraz systemy uruchamiające kod użytkowników. Ponieważ page cache jest współdzielony na poziomie hosta, podatność może potencjalnie zostać wykorzystana jako element ucieczki z kontenera lub kompromitacji współdzielonego środowiska. 

Dodatkowym problemem jest ograniczona widoczność ataku z perspektywy standardowych mechanizmów bezpieczeństwa. Modyfikacja zachodzi wyłącznie w pamięci operacyjnej, dlatego narzędzia monitorujące integralność plików na dysku mogą nie wykryć żadnych zmian. Po restarcie systemu zmodyfikowana zawartość page cache znika, jednak wcześniej uzyskane uprawnienia roota pozostają realnym zagrożeniem operacyjnym. 

Główną rekomendacją pozostaje aktualizacja jądra Linux do wersji zawierającej poprawkę eliminującą podatną ścieżkę przetwarzania. W sytuacjach, w których natychmiastowa aktualizacja nie jest możliwa, rekomendowane jest ograniczenie lub blokowanie dostępu do AF_ALG, np. przy użyciu seccomp lub wyłączenia modułu algif_aead. 

Patrząc szerzej

Podatność została odkryta przy użyciu narzędzi wspomaganych przez AI analizujących kod jądra Linux. Zbiega się to czasowo z rosnącą dyskusją wokół modeli zdolnych do prowadzenia zaawansowanej analizy bezpieczeństwa, w tym opublikowanego niedawno przez Anthropic systemu Claude Mythos, który według deklaracji producenta osiąga wysoką skuteczność w identyfikacji złożonych błędów logicznych i podatności zero-day. 

Z perspektywy bezpieczeństwa operacyjnego istotny jest fakt, że exploit omija klasyczne mechanizmy monitorowania integralności plików, ponieważ modyfikacja zachodzi wyłącznie w page cache. 

Więcej informacji:  
https://copy.fail/ 
https://xint.io/blog/copy-fail-linux-distributions