Przez 93 minuty instalowanie "oficjalnego" CLI Bitwarden zamieniało laptopy w narzędzia do przejmowania kont GitHub

22 kwietnia złośliwa wersja interfejsu wiersza poleceń Bitwarden pojawiła się w npm pod oficjalną nazwą pakietu @bitwarden/cli@2026.4.0. Przez 93 minuty każdy, kto pobrał CLI przez npm, otrzymywał podstawioną wersję z backdoorem zamiast legalnego narzędzia.

Bitwarden wykrył kompromitację, usunął pakiet i wydał oświadczenie, w którym stwierdził, że nie znalazł dowodów na to, że atakujący uzyskali dostęp do danych skarbca użytkowników końcowych lub skompromitowali systemy produkcyjne.

Firma badań bezpieczeństwa JFrog przeanalizowała złośliwy ładunek i stwierdziła, że nie był on szczególnie zainteresowany skarbcami Bitwarden. Celował w tokeny GitHub, tokeny npm, klucze SSH, historię powłoki, poświadczenia AWS, poświadczenia GCP, poświadczenia Azure, sekrety GitHub Actions oraz pliki konfiguracyjne narzędzi AI.

Są to poświadczenia, które regulują sposób, w jaki zespoły budują, wdrażają i uzyskują dostęp do swojej infrastruktury.

Bitwarden obsługuje ponad 50 000 firm i 10 milionów użytkowników, a jego własna dokumentacja opisuje CLI jako „potężny, w pełni funkcjonalny" sposób dostępu do skarbca i zarządzania nim, w tym w zautomatyzowanych przepływach pracy uwierzytelnianych przy użyciu zmiennych środowiskowych.

Bitwarden wymienia npm jako najprostszą i preferowaną metodę instalacji dla użytkowników już zaznajomionych z rejestrem. Ta kombinacja użycia automatyzacji, instalacji na maszynach deweloperskich i oficjalnej dystrybucji npm umieszcza CLI dokładnie tam, gdzie zwykle przechowywane są wysokowartościowe sekrety infrastrukturalne.

Analiza JFrog pokazuje, że złośliwy pakiet przeprogramował zarówno hook preinstall, jak i punkt wejścia binarnego bw do loadera, który pobierał środowisko uruchomieniowe Bun i uruchamiał zaciemniony ładunek. Kompromitacja jest wyzwalana w czasie instalacji i w czasie wykonywania.

Organizacja mogła uruchamiać CLI z backdoorem bez dotykania jakichkolwiek przechowywanych haseł, podczas gdy złośliwe oprogramowanie systematycznie zbierało poświadczenia zarządzające jej potokami CI, kontami chmurowymi i automatyzacją wdrożeń.

Firma bezpieczeństwa Socket twierdzi, że atak wydaje się wykorzystywać skompromitowaną GitHub Action w potoku CI/CD Bitwarden, co jest zgodne ze wzorcem śledzonym przez badaczy Checkmarx.

Bitwarden potwierdził, że incydent jest powiązany z szerszą kampanią łańcucha dostaw Checkmarx.

Wąskie gardło zaufania

Npm zbudował swój model zaufanego publikowania, aby rozwiązać dokładnie tę klasę ryzyka.

Zastępując długotrwałe tokeny publikowania npm uwierzytelnianiem CI/CD opartym na OIDC, system usuwa jedną z najczęstszych ścieżek, z których korzystają atakujący, aby przejąć wydania rejestru, a npm zaleca zaufane publikowanie i traktuje to jako znaczący krok naprzód.

Trudniejszą powierzchnią jest sama logika wydań, czyli przepływy pracy i akcje, które wywołują krok publikowania. Własna dokumentacja npm zaleca kontrole wykraczające poza OIDC, takie jak środowiska wdrożeniowe z wymaganiami ręcznego zatwierdzania, reguły ochrony tagów i ograniczenia gałęzi.

Ustawienia środowiska GitHub pozwalają organizacjom wymagać akceptacji recenzentów przed wdrożeniem przepływu pracy. Framework SLSA idzie dalej, prosząc konsumentów o weryfikację, czy proweniencja odpowiada oczekiwanym parametrom, takim jak poprawne repozytorium, gałąź, tag, przepływ pracy i konfiguracja budowania.

Incydent Bitwarden pokazuje, że trudniejszy problem tkwi w warstwie przepływu pracy. Jeśli atakujący może wykorzystać sam przepływ pracy wydania, odznaka „oficjalny" nadal towarzyszy złośliwemu pakietowi.

Zaufane publikowanie przenosi ciężar zaufania w górę, do integralności przepływów pracy i akcji, które je wywołują — warstwy, którą organizacje w dużej mierze pozostawiły niezbadaną.

Jeden token do wielu drzwi

Dla zespołów deweloperskich i infrastrukturalnych, skompromitowany przepływ pracy wydania naraża potoki CI, infrastrukturę automatyzacji i poświadczenia nimi zarządzające.

Analiza JFrog pokazuje, że gdy złośliwe oprogramowanie uzyskało token GitHub, mogło zweryfikować token, wyliczyć zapisywalne repozytoria, wylistować sekrety GitHub Actions, utworzyć gałąź, zatwierdzić przepływ pracy, poczekać na jego wykonanie, pobrać wynikowe artefakty, a następnie wyczyścić ślady.

Uzyskanie tokenu tworzy zautomatyzowany łańcuch, który przekształca jedno skradzione poświadczenie w trwały dostęp do całej infrastruktury automatyzacji organizacji.

Laptop dewelopera, który zainstaluje zatruty oficjalny pakiet, staje się mostem między lokalnym magazynem poświadczeń hosta a dostępem do GitHub i wszystkim, do czego dany token GitHub może dotrzeć.

Incydent Bybit jest bliską strukturalną analogią. Skompromitowana stacja robocza dewelopera pozwoliła atakującym zatruć zaufany interfejs upstream, który następnie dotarł do procesu operacyjnego ofiary.

Różnica polega na tym, że Bybit dotyczył zmodyfikowanego interfejsu webowego Safe, podczas gdy Bitwarden dotyczył zmodyfikowanego oficjalnego pakietu npm.

W środowiskach kryptowalutowych, fintech lub powierniczych ta ścieżka może prowadzić od magazynu poświadczeń do sygnatariuszy wydań, dostępu do chmury i systemów wdrożeniowych bez dotykania jakiegokolwiek wpisu skarbca.

W ciągu 60 dni Checkmarx ujawnił skompromitowane przepływy pracy GitHub Actions i wtyczki OpenVSX, a Cloud Security Alliance ostrzegł, że kampania TeamPCP aktywnie kompromituje projekty open-source i komponenty automatyzacji CI/CD.

JFrog udokumentował, jak skompromitowana GitHub Action Trivy wyeksfiltrował token publikowania LiteLLM i umożliwił złośliwe wydania PyPI, a Axios ujawnił, że dwie złośliwe wersje npm były w obiegu przez około trzy godziny przez skompromitowane konto opiekuna.

Sonatype naliczył ponad 454 600 nowych złośliwych pakietów tylko w 2025 roku, co łącznie daje ponad 1,2 miliona. Bitwarden dołącza do łańcucha incydentów potwierdzających, że przepływy pracy wydań i rejestry pakietów są główną powierzchnią ataku.

Dokładna przyczyna źródłowa nie jest jeszcze publiczna, ponieważ Bitwarden potwierdził powiązanie z kampanią Checkmarx, ale nie opublikował szczegółowego zestawienia tego, jak atakujący uzyskał dostęp do potoku wydań.

Skutki ataku

Najsilniejszym rezultatem dla obrońców jest to, że ten incydent przyspiesza redefinicję tego, co oznacza „oficjalny".

Dziś zaufane publikowanie dołącza dane proweniencji do każdego wydanego pakietu, potwierdzając tym samym tożsamość wydawcy w rejestrze. SLSA explicite dokumentuje wyższy standard dla weryfikatorów sprawdzających, czy proweniencja odpowiada oczekiwanemu repozytorium, gałęzi, przepływowi pracy i parametrom budowania.

Jeśli ten standard stanie się domyślnym zachowaniem konsumentów, „oficjalny" zacznie oznaczać „zbudowany przez właściwy przepływ pracy z właściwymi ograniczeniami", a atakujący, który skompromituje action, ale nie może spełnić wszystkich ograniczeń proweniencji, produkuje pakiet, który zautomatyzowani konsumenci odrzucają zanim zostanie zainstalowany.

Bardziej prawdopodobna krótkoterminowa ścieżka biegnie w przeciwnym kierunku. Atakujący wykazali w co najmniej 4 incydentach w ciągu 60 dni, że przepływy pracy wydań, zależności akcji i poświadczenia sąsiadujące z opiekunami przynoszą wysokowartościowe wyniki przy stosunkowo niskim nakładzie pracy.

Każdy kolejny incydent dodaje kolejną udokumentowaną technikę do publicznego podręcznika kompromitacji akcji, kradzieży tokenów z wyjść CI, przejęcia kont opiekunów i nadużycia zaufanych ścieżek publikowania.

Jeśli weryfikacja proweniencji nie stanie się domyślnym zachowaniem konsumentów, a nie opcjonalną warstwą polityki, oficjalne nazwy pakietów będą cieszyć się większym zaufaniem, niż ich procesy wydania mogą uzasadnić.

Wpis Przez 93 minuty instalowanie „oficjalnego" CLI Bitwarden zamieniało laptopy w platformy startowe do przejmowania kont GitHub pojawił się najpierw w CryptoSlate.