Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki typu supply chain coraz częściej obejmują już nie tylko biblioteki, zależności i pakiety, ale także rozszerzenia używane bezpośrednio w środowiskach programistycznych. Incydent związany z rozszerzeniem Nx Console dla Visual Studio Code pokazuje, że kompromitacja pojedynczego komponentu wykorzystywanego przez deweloperów może prowadzić do kradzieży sekretów, przejęcia tożsamości w ekosystemie CI/CD oraz dalszego rozprzestrzeniania złośliwego kodu w łańcuchu dostaw oprogramowania.
W tym przypadku zagrożenie dotknęło zaufanego narzędzia używanego do pracy z ekosystemem Nx. To sprawia, że atak ma szczególnie wysoką wagę operacyjną, ponieważ uderza w osoby posiadające dostęp do repozytoriów, tokenów publikacyjnych, chmury i systemów automatyzacji.
W skrócie
Wersja 18.95.0 rozszerzenia Nx Console opublikowana w Microsoft Visual Studio Code Marketplace została skompromitowana i wykorzystana do uruchamiania wieloetapowego malware na stacjach roboczych programistów. Złośliwy komponent miał pobierać i wykonywać dodatkowy, zaciemniony ładunek odpowiedzialny za kradzież poświadczeń oraz danych uwierzytelniających używanych podczas tworzenia i publikacji oprogramowania.
Incydent dotyczył rozszerzenia identyfikowanego jako rwl.angular-console. Z dostępnych informacji wynika, że problem nie objął wersji dystrybuowanej przez Open VSX. Maintainerzy projektu zalecili aktualizację do wersji 18.100.0 lub nowszej oraz pełną rotację wszystkich sekretów, które mogły być dostępne z potencjalnie zainfekowanego hosta.
Kontekst / historia
Nx Console to popularny zestaw narzędzi wspierających pracę z ekosystemem Nx w takich środowiskach jak Visual Studio Code, Cursor i JetBrains. Ze względu na skalę użycia kompromitacja tego typu rozszerzenia daje atakującym atrakcyjny wektor wejścia do środowisk developerskich i procesów publikacji artefaktów.
Według ujawnionych informacji źródłem incydentu było przejęcie poświadczeń jednego z deweloperów zaangażowanych w rozwój rozszerzenia. Uzyskany dostęp miał zostać wykorzystany do wprowadzenia niepodpisanego, osieroconego commitu do repozytorium projektu, co ostatecznie doprowadziło do opublikowania złośliwej wersji. To kolejny przykład sytuacji, w której cyberprzestępcy nie muszą atakować infrastruktury ofiary bezpośrednio — wystarczy przejęcie zaufanego kanału dystrybucji.
Analiza techniczna
Mechanizm infekcji został zaprojektowany tak, aby aktywować się bardzo wcześnie, praktycznie natychmiast po otwarciu dowolnego workspace w Visual Studio Code. Składnik rozszerzenia pobierał dodatkowy ładunek o zaciemnionej zawartości, a następnie wykonywał go lokalnie. Wieloetapowy charakter ataku utrudniał szybką analizę i detekcję.
Łańcuch działania obejmował instalację środowiska Bun oraz uruchomienie zaciemnionego pliku JavaScript odpowiedzialnego za dalsze operacje na hoście. Malware prowadziło rozpoznanie środowiska, unikało infekowania systemów znajdujących się prawdopodobnie w strefach czasowych Rosji i krajów WNP, a następnie działało jako odłączony proces w tle.
Najgroźniejszym elementem kampanii była funkcja kradzieży sekretów deweloperskich. Z opublikowanych ustaleń wynika, że złośliwe oprogramowanie mogło pozyskiwać dane z sejfów 1Password, konfiguracji Anthropic Claude Code oraz poświadczenia powiązane z npm, GitHub i AWS. Oznacza to, że celem były nie tylko dane lokalne, lecz także tożsamości i tokeny umożliwiające publikację pakietów, dostęp do repozytoriów i operacje w środowiskach chmurowych.
Szczególnie istotny z perspektywy bezpieczeństwa łańcucha dostaw jest fakt, że analizowany ładunek zawierał integrację z Sigstore, w tym funkcje związane z wystawianiem certyfikatów oraz generowaniem metadanych provenance w modelu SLSA. W praktyce mogłoby to umożliwić wykorzystanie przejętych tokenów OIDC do publikowania złośliwych pakietów wyglądających jak poprawnie podpisane i wiarygodnie zbudowane artefakty.
Wskaźniki kompromitacji obejmowały obecność określonych plików na dysku, artefaktów w katalogach tymczasowych i LaunchAgents w systemie macOS, a także procesów Python uruchamiających komponent cat.py lub procesów ze zmienną środowiskową __DAEMONIZED=1. Okno ekspozycji dla złośliwej wersji 18.95.0 miało obejmować krótki przedział czasowy 18 maja 2026 roku.
Konsekwencje / ryzyko
Skutki incydentu wykraczają daleko poza pojedynczą stację roboczą programisty. Przejęte sekrety mogły zostać użyte do eskalacji działań w całym cyklu wytwarzania oprogramowania, od dostępu do kodu źródłowego po publikację złośliwych artefaktów.
- publikacja złośliwych pakietów w rejestrach oprogramowania,
- uzyskanie dostępu do prywatnych repozytoriów i pipeline’ów CI/CD,
- przejęcie środowisk chmurowych poprzez skradzione klucze i tokeny,
- utrzymanie persystencji na urządzeniach programistów,
- wtórne ataki na klientów i użytkowników końcowych korzystających z budowanych artefaktów.
Incydent pokazuje również ograniczenia klasycznych modeli zaufania. Nawet podpisy, provenance i mechanizmy potwierdzające pochodzenie artefaktów mogą zostać osłabione, jeśli atakujący przejmie legalne tokeny i kanały publikacji. Dla organizacji rozwijających oprogramowanie oznacza to konieczność traktowania środowisk developerskich jako infrastruktury krytycznej.
Rekomendacje
Organizacje, które mogły korzystać z podatnej wersji rozszerzenia, powinny niezwłocznie przeprowadzić działania reagowania na incydent. W pierwszej kolejności należy ustalić, czy na stacjach roboczych była zainstalowana wersja 18.95.0 w czasie wskazanego okna ekspozycji. Następnie trzeba usunąć zainfekowaną wersję i przejść na wydanie 18.100.0 lub nowsze.
Kolejnym krokiem powinna być pełna rotacja wszystkich sekretów, które mogły być dostępne z zainfekowanego hosta. Dotyczy to zwłaszcza tokenów GitHub, npm i AWS, kluczy SSH, danych z menedżerów haseł oraz wszelkich poświadczeń używanych przez narzędzia deweloperskie i automatyzację CI/CD.
- przeskanować hosty pod kątem wskazanych artefaktów i procesów,
- zweryfikować historię publikacji pakietów oraz aktywność kont deweloperskich,
- przeanalizować logi GitHub, rejestrów pakietów i systemów chmurowych pod kątem nietypowych zdarzeń,
- ograniczyć uprawnienia tokenów do niezbędnego minimum,
- wdrożyć krótkotrwałe poświadczenia i silne mechanizmy rotacji,
- wymusić ochronę kont maintainerów przez MFA odporne na phishing,
- rozdzielić środowiska developerskie od kont używanych do publikacji produkcyjnych artefaktów.
Dodatkowo warto wdrożyć monitoring integralności rozszerzeń IDE, walidację źródeł instalowanych pluginów oraz kontrolę egressu sieciowego ze stacji roboczych deweloperów. Rozszerzenia edytorów powinny być objęte takim samym poziomem nadzoru jak zależności aplikacyjne i obrazy kontenerowe.
Podsumowanie
Kompromitacja Nx Console 18.95.0 to ważny przykład nowoczesnego ataku na łańcuch dostaw skierowanego bezpośrednio w środowisko pracy programistów. Atakujący wykorzystali przejęte poświadczenia dewelopera do dystrybucji złośliwej wersji rozszerzenia, która uruchamiała malware kradnące sekrety i potencjalnie umożliwiające dalsze zatrucie ekosystemu pakietów.
Najważniejszy wniosek dla zespołów bezpieczeństwa jest jednoznaczny: rozszerzenia IDE, tokeny publikacyjne, systemy build oraz stacje robocze deweloperów muszą być traktowane jako newralgiczne elementy łańcucha dostaw. Ochrona tych obszarów wymaga nie tylko klasycznej higieny bezpieczeństwa, ale także ciągłej obserwacji, silnej kontroli tożsamości i gotowości do szybkiej rotacji zaufania po każdym incydencie.
Źródła
- The Hacker News — https://thehackernews.com/2026/05/compromised-nx-console-18950-targeted.html
- GitHub Security Advisories: nrwl/nx — https://github.com/nrwl/nx/security/advisories
- Microsoft Visual Studio Marketplace — Nx Console — https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console