Wprowadzenie do problemu / definicja
Kampania GlassWorm pokazuje, jak gwałtownie ewoluują ataki na łańcuch dostaw oprogramowania. W najnowszej odsłonie przestępcy wykorzystali ekosystem Open VSX, czyli otwarty rejestr rozszerzeń zgodnych z Visual Studio Code i jego pochodnymi, aby dostarczać złośliwe komponenty do środowisk deweloperskich.
Kluczową cechą tej operacji jest nadużycie zaufania do rozszerzeń oraz mechanizmów zależności między nimi. Dzięki temu malware może trafić do ofiary pośrednio, za pośrednictwem dodatku, który na pierwszy rzut oka wygląda na legalny i przydatny.
W skrócie
W marcu 2026 roku badacze opisali falę aktywności GlassWorm wymierzoną w użytkowników Open VSX. Zidentyfikowano co najmniej 72 złośliwe rozszerzenia podszywające się pod popularne narzędzia programistyczne, w tym linery, formatery, uruchamiacze kodu oraz dodatki związane z narzędziami AI.
Najważniejszym elementem kampanii było wykorzystanie pól extensionPack i extensionDependencies, które pozwalają jednemu rozszerzeniu automatycznie instalować inne. To właśnie w tych dodatkowych komponentach umieszczano adekwatny ładunek malware, co znacząco utrudniało wykrycie zagrożenia.
- atak objął dziesiątki rozszerzeń w Open VSX,
- złośliwy kod dostarczano pośrednio przez zależności,
- kampania była powiązana z aktywnością obserwowaną również w GitHub i npm,
- celem były tokeny, sekrety, dane uwierzytelniające i informacje ze stacji roboczych deweloperów.
Kontekst / historia
GlassWorm był już wcześniej łączony z atakami na narzędzia używane przez programistów. Operatorzy tej kampanii konsekwentnie koncentrują się na punktach, w których powstaje kod, przechowywane są sekrety i uruchamiane są procesy publikacyjne.
To podejście jest szczególnie niebezpieczne, ponieważ kompromitacja środowiska deweloperskiego może otworzyć drogę nie tylko do kradzieży danych, ale także do dalszego skażenia repozytoriów, pipeline’ów CI/CD i finalnych wydań oprogramowania. W praktyce jeden zainfekowany komponent może uruchomić znacznie szerszy incydent organizacyjny.
Nowa fala wpisuje się też w rosnący trend ataków na supply chain, w których przestępcy nie opierają się już wyłącznie na klasycznych plikach wykonywalnych. Coraz częściej wykorzystują legalne aktualizacje, zależności, commity i rozszerzenia, które wyglądają na autentyczne i zgodne z normalnym workflow zespołu.
Analiza techniczna
Najważniejsza zmiana techniczna w kampanii polega na odejściu od prostego modelu, w którym każde złośliwe rozszerzenie zawiera własny loader. Atakujący wykorzystali natywne funkcje Open VSX, pozwalające deklarować pakiety rozszerzeń oraz zależności wymagane do działania.
W efekcie rozszerzenie o pozornie nieszkodliwej funkcji mogło automatycznie pobierać kolejny komponent zawierający adekwatny payload. Taki model jest szczególnie trudny do wychwycenia, ponieważ pierwotny dodatek może zachowywać się zgodnie z opisem i jednocześnie pełnić rolę kanału dostarczania malware.
Badacze zwrócili również uwagę na kontynuację wcześniejszych technik charakterystycznych dla GlassWorm. Należą do nich kontrole ustawień regionalnych systemu, wykorzystywane do unikania infekowania wybranych środowisk, a także bardziej zaawansowana obfuskacja kodu.
Istotnym wyróżnikiem kampanii jest także użycie transakcji Solana jako mechanizmu typu dead drop resolver. Zamiast odwoływać się do na stałe wpisanego serwera C2, złośliwy komponent może pobierać aktualne dane o infrastrukturze sterującej z informacji zapisanych w blockchainie. Z perspektywy obrońców zwiększa to odporność operacji na blokowanie i utrudnia budowanie trwałych wskaźników kompromitacji.
Równolegle zauważono stosowanie niewidocznych znaków Unicode do ukrywania fragmentów odpowiedzialnych za dekodowanie i pobieranie kolejnych etapów infekcji. Tego rodzaju technika sprawia, iż część kodu może wyglądać na pustą lub neutralną, mimo iż interpreter odczytuje ją jako aktywny element łańcucha ataku.
Na poziomie funkcjonalnym malware koncentruje się na kradzieży danych o wysokiej wartości operacyjnej:
- tokenów dostępowych do repozytoriów i rejestrów,
- sekretów przechowywanych w zmiennych środowiskowych,
- kluczy API i poświadczeń usług chmurowych,
- danych CI/CD,
- informacji systemowych przydatnych do dalszego profilowania ofiary.
Konsekwencje / ryzyko
Ryzyko związane z tą kampanią jest wysokie, ponieważ atak trafia bezpośrednio w proces wytwarzania oprogramowania. jeżeli przestępcy przejmą sekrety lub tokeny publikacyjne dewelopera, mogą wykorzystać je do dalszego rozprzestrzeniania złośliwego kodu w obrębie organizacji lub poza nią.
Szczególnie narażone są zespoły korzystające z dużej liczby pluginów, alternatywnych dystrybucji edytorów oraz dodatków wspierających AI. W takich środowiskach rozszerzenia są integralną częścią codziennej pracy, więc złośliwa aktywność może długo pozostawać niezauważona.
Dodatkowym problemem jest wieloplatformowy charakter operacji. Powiązania między Open VSX, GitHub i npm sugerują, iż sprawcy budują cały ekosystem infekcji, w którym kompromitacja jednego elementu wspiera kolejne etapy ataku. To zwiększa skalę ryzyka dla organizacji opierających development na wielu zewnętrznych źródłach komponentów.
Rekomendacje
Organizacje powinny traktować rozszerzenia IDE jako pełnoprawny element powierzchni ataku. Oznacza to potrzebę wdrożenia podobnych mechanizmów kontroli, jakie stosuje się wobec bibliotek, kontenerów i pakietów systemowych.
- ograniczyć instalację rozszerzeń wyłącznie do zatwierdzonej listy,
- monitorować zmiany w zależnościach rozszerzeń, zwłaszcza w polach extensionPack i extensionDependencies,
- regularnie audytować zainstalowane pluginy i ich uprawnienia,
- weryfikować rozszerzenia publikowane przez mało znanych autorów,
- skanować stacje deweloperskie pod kątem kradzieży sekretów i nietypowych procesów uruchamianych przez edytory,
- wdrożyć wykrywanie ukrytych znaków Unicode w kodzie, konfiguracjach i paczkach publikacyjnych,
- stosować zasadę minimalnych uprawnień dla tokenów oraz regularną rotację sekretów,
- wymuszać MFA dla kont w rejestrach, repozytoriach i platformach CI/CD,
- segmentować środowiska deweloperskie od systemów produkcyjnych,
- przygotować procedury szybkiego unieważniania tokenów po wykryciu kompromitacji.
Podsumowanie
GlassWorm potwierdza, iż nowoczesne ataki supply chain coraz częściej opierają się na legalnych funkcjach ekosystemów programistycznych. Nadużycie zależności w Open VSX, wykorzystanie ukrywania kodu z pomocą Unicode oraz odwołania do blockchainu jako warstwy pośredniej dla infrastruktury C2 świadczą o dojrzałej i elastycznej operacji wymierzonej w deweloperów.
Dla organizacji to wyraźny sygnał, iż bezpieczeństwo procesu tworzenia systemu nie może kończyć się na skanowaniu bibliotek i repozytoriów. Taki sam poziom kontroli musi objąć edytory, rozszerzenia, konta deweloperskie i wszystkie zewnętrzne komponenty używane podczas pracy nad kodem.
Źródła
- The Hacker News – GlassWorm Supply-Chain Attack Abuses 72 Open VSX Extensions to Target Developers — https://thehackernews.com/2026/03/glassworm-supply-chain-attack-abuses-72.html
- Socket – GlassWorm Loader Hits Open VSX via Suspected Developer Account Compromise — https://socket.dev/blog/glassworm-loader-hits-open-vsx-via-suspected-developer-account-compromise
- Aikido – The Return of the Invisible Threat: Hidden PUA Unicode Hits GitHub Repositories — https://www.aikido.dev/blog/the-return-of-the-invisible-threat-hidden-pua-unicode-hits-github-repositorties
- Eclipse Foundation Staff Blogs – Open VSX security update, October 2025 — https://blogs.eclipse.org/post/mika%C3%ABl-barbero/open-vsx-security-update-october-2025
- Endor Labs – PhantomRaven or Research Experiment? — https://www.endorlabs.com/learn/phantomraven-or-research-experiment
