Skala ataku na GitHub: zatruta wtyczka VS Code i 3800 repozytoriów
GitHub potwierdził wyciek z około 3800 wewnętrznych repozytoriów po tym, jak pracownik zainstalował złośliwą wtyczkę VS Code. Atak grupy TeamPCP pokazuje, jak duże znaczenie ma bezpieczeństwo stacji developerskich.
W połowie maja 2026 roku GitHub potwierdził, że w wyniku ataku na łańcuch dostaw doszło do wycieku danych z około 3800 wewnętrznych repozytoriów. Przyczyną nie było zaawansowane włamanie do serwerów, ale instalacja złośliwego rozszerzenia do edytora VS Code na komputerze jednego z pracowników. Sprawcą jest grupa TeamPCP, która w ostatnich miesiącach przeprowadziła serię podobnych ataków na ekosystem open source. To kolejny sygnał, że bezpieczeństwo stacji developerskich stało się newralgicznym elementem ochrony organizacji.
Jak doszło do wycieku z GitHub
Jak wynika z analizy opublikowanej przez SecurityWeek, atakujący wykorzystali rozszerzenie do Visual Studio Code, które po instalacji na komputerze programisty uzyskało dostęp do jego środowiska pracy. VS Code rozszerzenia domyślnie mają pełny dostęp do danych na maszynie dewelopera – w tym do poświadczeń, kluczy SSH, kluczy do chmury i wszystkich innych sekretów. W tym przypadku jedno zainfekowane rozszerzenie wystarczyło, by przestępcy przejęli dostęp do wewnętrznych repozytoriów GitHub.
Platforma potwierdziła skalę incydentu około pięciu godzin po tym, jak grupa TeamPCP pochwaliła się włamaniem na undergroundowym forum. „Nasza obecna ocena wskazuje, że aktywność ograniczała się do wycieku repozytoriów wewnętrznych GitHub. Twierdzenia atakującego o około 3800 repozytoriach są zgodne z kierunkiem naszego dochodzenia” – przekazał GitHub w oficjalnym komunikacie. Firma nie ujawniła, jakie konkretnie rozszerzenie zostało wykorzystane ani jakie dane znajdowały się na skompromitowanym komputerze.
Po wykryciu włamania GitHub natychmiast zaczął rotować krytyczne sekrety, priorytetyzując poświadczenia o najwyższym znaczeniu. „Kontynuujemy analizę logów, weryfikację rotacji sekretów i monitorowanie ewentualnych działań następczych” – dodano w oświadczeniu. Obiecany został pełny raport powłamaniowy w późniejszym terminie.
TeamPCP i seria ataków na łańcuch dostaw
Grupa TeamPCP nie jest nowym graczem. Jak opisuje BleepingComputer, wcześniej przeprowadziła kampanię Shai-Hulud, w ramach której opublikowała na platformie npm dziesiątki zainfekowanych pakietów TanStack. Kod kradnący poświadczenia został wykonany w środowiskach CI/CD wielu firm, w tym Grafany. W tym przypadku jeden token GitHuba, który nie został zrotowany podczas reagowania na incydent, pozwolił atakującym na dostęp do prywatnych repozytoriów. Grafana potwierdziła kradzież kodu źródłowego oraz danych kontaktowych pracowników biznesowych.
TeamPCP odpowiada także za ataki na Trivy, Checkmarx, Bitwarden CLI, Mistral AI oraz UiPath – wszystkie w 2026 roku. Jak zauważył Mackenzie Jackson z Aikido Security, cytowany przez SecurityWeek: „Pojedyncze rozszerzenie VS Code na maszynie jednego pracownika wystarczyło, by uzyskać dostęp do 3800 repozytoriów GitHub. Większość zespołów bezpieczeństwa nadal nie ma wglądu w to, jakie rozszerzenia lub pakiety znajdują się na komputerach deweloperów”.
Dlaczego stacje developerskie są celem numer jeden
Ataki na łańcuch dostaw oprogramowania nie są nowe, ale zmienił się ich wektor. Zamiast atakować bezpośrednio serwery produkcyjne, przestępcy celują w maszyny programistów. Zainfekowane rozszerzenia IDE, zatrute pakiety npm, fałszywe biblioteki – każde z tych narzędzi może pełnić funkcję trojana, który po uruchomieniu w zaufanym środowisku programisty wykrada dane uwierzytelniające.
Specyfika takich ataków polega na tym, że złośliwe działanie odbywa się w ramach procesu uznawanego za legalny. Programista instaluje rozszerzenie, by przyspieszyć pracę, a ono w tle przechwytuje tokeny, klucze SSH czy hasła do repozytoriów. Ponieważ działanie jest realizowane z poziomu zaufanego narzędzia, tradycyjne systemy bezpieczeństwa rzadko podnoszą alarm.
W przypadku GitHub atakujący nie musieli przełamywać zabezpieczeń platformy – wystarczyło, że uzyskali dostęp do środowiska jednego pracownika. To pokazuje, że nawet najlepiej chroniona infrastruktura chmurowa może zostać naruszona przez słabe ogniwo w postaci stacji developerskiej.
Praktyczne wnioski dla firm i administratorów
Incydent z GitHub nie wymaga panicznej reakcji, ale skłania do przemyślenia polityk bezpieczeństwa w organizacjach, które rozwijają oprogramowanie. Przede wszystkim warto ograniczyć liczbę używanych rozszerzeń VS Code i regularnie audytować ich pochodzenie. Rozszerzenia powinny pochodzić wyłącznie z zaufanych źródeł i być sprawdzane pod kątem aktualizacji oraz zmian w uprawnieniach.
Drugim kluczowym działaniem jest rotacja tokenów i kluczy dostępowych po każdym incydencie, nawet jeśli początkowo wydaje się, że nie były zagrożone. Jak pokazał przypadek Grafany, „pominięty” token może prowadzić do dalszej kompromitacji. Warto wdrożyć automatyzację rotacji sekretów i skrócić czas życia tymczasowych poświadczeń.
Trzeci obszar to monitorowanie aktywności na stacjach developerskich. Narzędzia EDR i skanery zachowań mogą wykryć próby odczytu plików z sekretami czy nietypowe połączenia sieciowe, nawet jeśli pochodzą z procesów takich jak Node.js czy VS Code. Wreszcie, niezbędne jest egzekwowanie zasady najmniejszych uprawnień – tokeny używane w CI/CD powinny mieć dostęp tylko do tych repozytoriów, które są niezbędne do pracy danego dewelopera.
Incydent z GitHub nie jest odosobniony. To część trendu, w którym ataki na łańcuch dostaw oprogramowania przenoszą się na maszyny programistów. Firmy, które zainwestują w bezpieczeństwo środowisk developerskich, zyskają realną ochronę nie tylko przed TeamPCP, ale i przed kolejnymi grupami, które pójdą tą samą ścieżką.
