22 kwietnia 2026 roku, przez niecałą godzinę i dwadzieścia cztery minuty, każdy kto pobrał obraz Docker z oficjalnego repozytorium checkmarx/kics instalował złośliwy kod. Nie z podrobionej kopii repozytroium. Nie z fałszywej domeny. Z oficjalnego, zweryfikowanego repozytorium Docker Hub firmy, której narzędzie istnieje właśnie po to, żeby znajdować błędy bezpieczeństwa w kodzie.
To jest historia o tym, że narzędzia DevSecOps — skanery bezpieczeństwa, analizatory infrastruktury jako kodu, menedżery haseł dla deweloperów — stały się wartościowym celem ataków na łańcuch dostaw. I o tym, że zaufanie do tych narzędzi jest dokładnie tą właściwością, która czyni je użyteczną bronią.
KICS: skaner bezpieczeństwa który skanował dla atakujących
KICS — Keeping Infrastructure as Code Secure — to skaner open source Checkmarx analizujący konfiguracje Terraform, Kubernetes, CloudFormation i innych narzędzi infrastrukturalnych pod kątem błędów bezpieczeństwa. Narzędzie jest szeroko używane w potokach CI/CD jako automatyczna warstwa weryfikacji: zanim kod infrastrukturalny trafi do środowiska produkcyjnego, KICS sprawdza czy nie zawiera nieprawidłowych uprawnień, otwartych portów, niezaszyfrowanych danych.
Żeby wykonać tę pracę, KICS potrzebuje dostępu do plików konfiguracyjnych infrastruktury. Te pliki regularnie zawierają tokeny dostępu do chmury, klucze API, dane uwierzytelniające do baz danych, certyfikaty. KICS musi je widzieć — żeby je weryfikować.
Atakujący dostrzegli w tym piękną symetrię. Jeśli można skompromitować KICS i sprawić żeby poza weryfikacją robił coś jeszcze — szyfrował wyniki skanowania i wysyłał je na zewnętrzny serwer — to każda organizacja, która uruchomiła KICS na swojej infrastrukturze, właśnie dobrowolnie dostarczyła atakującemu kompletną mapę sekretów produkcyjnych.
84 minuty okna, trzy kanały dystrybucji
Złośliwe obrazy były dostępne w oknie między 14:17:59 a 15:41:31 UTC 22 kwietnia. Osiemdziesiąt cztery minuty. W tym czasie Docker Hub serwował zainfekowane obrazy pod tagami v2.1.20, v2.1.20-debian, alpine, debian i latest — plus nowo wprowadzony tag v2.1.21, który nie odpowiadał żadnemu legitymizowanemu wydaniu.
Ale Docker Hub to był tylko jeden kanał. Równolegle zaatakowane zostały rozszerzenia VS Code i Open VSX — dwie wersje rozszerzenia checkmarx/cx-dev-assist (1.17.0 i 1.19.0) oraz checkmarx/ast-results (2.63.0 i 2.66.0) zawierały ukryty mechanizm pobierający dodatkowy ładunek mcpAddon.js przez środowisko uruchomieniowe Bun. Łączna liczba instalacji tych rozszerzeń przekraczała tysiąc w momencie analizy.
Trzy kanały dystrybucji, jedna kampania, jeden dzień. Jak komentuje Eli Woodward z Team Cymru: "Zamiast efektownych zero-dayów czy wyrafinowanych kampanii phishingowych, TeamPCP metodycznie nadużywa zaufanych zasobów w naszych ekosystemach technologicznych."
Robak który sam się rozprzestrzenia
Najciekawszy technicznie element tej kampanii nie jest w samym złośliwym kodzie KICS — jest w tym co ten kod robi po wyciągnięciu pierwszych tokenów.
Złośliwy ładunek po uzyskaniu tokenu GitHub nie kończy pracy. Używa tego tokenu do wstrzyknięcia złośliwego przepływu pracy GitHub Actions do repozytoriów, do których ofiara ma dostęp zapisu. Nowy przepływ pracy przechwytuje sekrety dostępne dla następnych uruchomień CI/CD i wyciąga tokeny npm. Te tokeny npm są używane do publikowania złośliwych wersji pakietów ofiary na rejestrze publicznym.
Robak się replikuje. Jeden zainfekowany deweloper z uprawnieniami zapisu do wielu repozytoriów to jeden punkt wejścia do dziesiątek potoków CI/CD — i dziesiątek zestawów sekretów produkcyjnych.
GitGuardian dokumentuje jeden potwierdzony przypadek: Dependabot automatycznie pobrał zatrute checkmarx/kics:latestpodczas rutynowej aktualizacji zależności, uruchamiając ładunek w CI z pełnym dostępem do sekretów repozytorium. Automatyczna aktualizacja zależności — mechanizm zaprojektowany żeby poprawiać bezpieczeństwo — stała się wektorem kompromitacji.
Bitwarden jako ofiara domino
To jest moment, w którym historia przekracza ramy jednej kampanii.
Bitwarden CLI — narzędzie wiersza poleceń popularnego menedżera haseł open source — używa w swoim potoku CI/CD akcji checkmarx/ast-github-action. Ta akcja była jednym z artefaktów skompromitowanych w kampanii marcowej TeamPCP. Skradzione dane uwierzytelniające z tego kompromitacji pozwoliły atakującym wstrzyknąć złośliwy kod do procesu budowania Bitwarden CLI.
Między 17:57 a 19:30 ET 22 kwietnia pakiet @bitwarden/cli@2026.4.0 na rejestrze npm zawierał złośliwy plik bw1.js. Bitwarden CLI jest powszechnie integrowany z potokami deweloperskimi i środowiskami automatyzacji — narzędzie do zarządzania hasłami, które ma dostęp do sekretów produkcyjnych, kompromitowane przez skompromitowane narzędzie bezpieczeństwa od innego vendora.
Bitwarden potwierdził incydent i podkreślił że dane skarbców użytkowników nie były zagrożone — co jest istotnym rozróżnieniem. Złośliwy kod celował w sekrety CI/CD środowiska deweloperskiego, nie w zaszyfrowane skarbce użytkowników. CVE dla wersji 2026.4.0 jest w przygotowaniu.
Połączenie między kampanią KICS a kompromitacją Bitwarden jest potwierdzone na poziomie infrastruktury: ten sam punkt końcowy eksfiltracji audit.checkmarx[.]cx/v1/telemetry, ta sama procedura zaciemniania __decodeScrambled z ziarnem 0x3039, ten sam wzorzec kradzieży danych uwierzytelniających i propagacji przez GitHub.
Ten sam wzorzec, nowe środowisko
Pisaliśmy o ataku na CPUID — podmienione odnośniki przez skompromitowany interfejs poboczny. O Smart Slider i Essential Plugin — zatrute aktualizacje przez oficjalny kanał dystrybucji wtyczek. O fałszywym instalatorze Claude i PlugX — podrobiona strona serwująca legalną aplikację z złośliwą biblioteką obok.
Kampania TeamPCP to ten sam wzorzec w środowisku DevSecOps. Różnica jest w tym kto jest celem i co ma dostęp.
Narzędzia bezpieczeństwa mają z założenia dostęp do wszystkiego co weryfikują. KICS skanuje konfiguracje infrastruktury — więc musi widzieć tokeny chmurowe i klucze API. Bitwarden CLI zarządza hasłami w potokach CI/CD — więc musi mieć dostęp do skarbca. Checkmarx GitHub Actions integruje się z repozytoriami — więc musi mieć uprawnienia zapisu.
Deweloper instalujący KICS żeby poprawić bezpieczeństwo swojej infrastruktury zakłada że to narzędzie jest bezpieczne. To założenie jest dokładnie tą właściwością, którą TeamPCP exploituje.
Jak działa exfiltracja i dlaczego jest trudna do wykrycia
Złośliwy ładunek szyfruje zebrane dane algorytmem AES-256-GCM i wysyła je na audit.checkmarx[.]cx/v1/telemetry — domenę zaprojektowaną żeby wyglądać jak legalny endpoint telemetryczny Checkmarx. Organizacje filtrujące ruch sieciowy na podstawie reputacji domeny nie mają podstaw do blokowania ruchu do domeny sugerującej że pochodzi od zaufanego vendora narzędzi bezpieczeństwa.
Jeśli połączenie z tym endpointem jest niedostępne — a prawdopodobnie będzie po wykryciu kampanii — malware ma mechanizm zapasowy: wyciąga alternatywne domeny eksfiltracji z publicznych commitów GitHuba opatrzonych sygnaturą beautifulcastle, a skradzione dane uploaduje jako zaszyfrowane pliki JSON do repozytoriów tworzonych na koncie ofiary na GitHubie. Organizacja może nie wiedzieć że jest ofiarą dopóki ktoś nie zauważy nowych publicznych repozytoriów z nazwami w formacie <słowo>-<słowo>-<3 cyfry>.
Co zrobić jeśli KICS lub Bitwarden CLI były w potoku
Dla KICS: niebezpieczne okno to 14:17:59–15:41:31 UTC 22 kwietnia. Organizacje które pobrały obraz Docker w tym oknie lub używają tagów latest, alpine, debian bez przypiętych skrótów obrazu powinny założyć kompromitację i rotować wszystkie sekrety dostępne dla środowiska CI/CD — tokeny GitHub, klucze chmurowe AWS/Azure/GCP, tokeny npm, klucze SSH.
Bezpieczne wersje: Docker KICS v2.1.20 (po przywróceniu), checkmarx/ast-github-action v2.3.36, rozszerzenia VS Code w wersjach v2.64.0 i v1.18.0.
Dla Bitwarden CLI: niebezpieczna wersja to wyłącznie @bitwarden/cli@2026.4.0 pobrana między 17:57 a 19:30 ET 22 kwietnia. Dane skarbców użytkowników nie były zagrożone — tylko sekrety CI/CD środowiska w którym działał CLI.
Szersza rekomendacja Sophos jest warta zapamiętania: "Jeśli Claude, Cursor, Aider lub pliki konfiguracyjne MCP były obecne na zainfekowanym hoście — zakładaj że ich zawartość została wyeksfiltrowana. Rotuj wszystkie wbudowane sekrety."
Podsumowanie
Kampania TeamPCP z 22 kwietnia jest modelowym przykładem ataku na infrastrukturę DevSecOps — warstwy narzędzi, która z definicji ma dostęp do wszystkiego co chroni.
KICS skompromitowany przez swojego własnego maintainera stał się skanerem który skanował dla atakujących. Bitwarden CLI skompromitowany przez zależność od zatrytego narzędzia Checkmarx stał się dystrybutorem złośliwego kodu przez oficjalny rejestr npm. Robak używający skradzionych tokenów GitHub do samodzielnej propagacji przekraczał granice między organizacjami automatycznie.
Pisaliśmy że WordPress jest de facto systemem operacyjnym dla milionów witryn — pytanie o to czy platforma jest systemem operacyjnym jest pytaniem o to kto ponosi odpowiedzialność za jej bezpieczeństwo. Stos DevSecOps jest systemem operacyjnym dla potoków wytwarzania oprogramowania. Pytanie o odpowiedzialność za jego bezpieczeństwo jest równie otwarte.
Źródła
Socket — pierwotna analiza kompromitacji obrazów Docker i rozszerzeń VS Code: https://socket.dev/blog/checkmarx-supply-chain-compromise
The Hacker News — szczegóły techniczne złośliwego kodu KICS i kampanii TeamPCP: https://thehackernews.com/2026/04/malicious-kics-docker-images-and-vs.html
BleepingComputer — kompromitacja Bitwarden CLI i połączenie z kampanią Checkmarx: https://www.bleepingcomputer.com/news/security/bitwarden-cli-npm-package-compromised-to-steal-developer-credentials/
Sophos X-Ops — analiza obu incydentów, wskaźniki kompromitacji i rekomendacje: https://www.sophos.com/en-us/blog/supply-chain-attacks-hit-checkmarx-and-bitwarden-developer-tools
GitGuardian — analiza mechanizmu robaka i przypadek Dependabot: https://blog.gitguardian.com/bitwarden-cli-gitguardian-views-on-helloworm00/
eSecurity Planet — kontekst kampanii i rekomendacje dla organizacji: https://www.esecurityplanet.com/threats/checkmarx-supply-chain-attack-exploits-docker-images-and-ci-cd-pipelines/
