Złośliwe rozszerzenie VS Code i 3800 repozytoriów GitHuba

Co dokładnie wydarzyło się w GitHubie?

GitHub wykrył i powstrzymał 18 maja 2026 r. kompromitację urządzenia pracownika, do której doszło przez złośliwe rozszerzenie VS Code opublikowane przez stronę trzecią. Firma usunęła rozszerzenie, odizolowała urządzenie i uruchomiła procedurę reagowania na incydent. Pierwszy publiczny komunikat opublikowano 20 maja, a 26 maja GitHub nadal opisywał dochodzenie jako trwające [1].

Ekosystem narzędzi dla programistów działa na łańcuchu zależności: edytor, rozszerzenia, agenci i integracja z repozytorium. Każde z tych ogniw jest zaufaniem, którego nikt nie sprawdza przy każdym uruchomieniu. W dziale AI do programowania opisujemy, jak te narzędzia są zbudowane i gdzie przebiegają ich granice zaufania.

Które rozszerzenie było wektorem ataku?

Pierwotny komunikat GitHuba nie podawał nazwy rozszerzenia, firma pisała wyłącznie o „poisoned VS Code extension” [1]. Źródła techniczne wskazują na Nx Console o identyfikatorze nrwl.angular-console w wersji 18.95.0. Według analizy StepSecurity ta wersja była dostępna w Marketplace około 11 minut, a złośliwy kod pobierał i uruchamiał dodatkowy payload. OpenVSX nie było objęte tym wydaniem [2].

Nazwa produktu pojawiła się w komunikatach Nx i w analizach niezależnych, a nie w pierwotnym oświadczeniu firmy [2]. Polskie media techniczne opisały sprawę, powołując się na komunikat GitHuba i wskazując Nx Console jako wektor [4].

Sedno problemu leży w uprawnieniach procesu edytora: rozszerzenie widzi pliki projektu i może otwierać połączenia sieciowe, co w tym przypadku posłużyło do pobrania kolejnego payloadu [2]. Ograniczanie zakresu poświadczeń dostępnych dla takich procesów rozwijamy w tekście o runtime’owym wstrzykiwaniu poświadczeń.

Ile repozytoriów obejmował incydent?

GitHub poinformował, że aktywność obejmowała eksfiltrację wewnętrznych repozytoriów, a twierdzenie atakującego o około 3800 repozytoriach określił jako kierunkowo zgodne z prowadzonym dochodzeniem („directionally consistent”) [1]. To nie jest opublikowany, ostateczny audyt liczby. Bezpieczniej pisać o „około 3800 repozytoriach według bieżącej oceny” niż o potwierdzonej i zamkniętej wartości [1].

Media techniczne podały tę samą wartość, powołując się na komunikat firmy [3][4]. Zakres dotyczy repozytoriów wewnętrznych GitHuba, nie potwierdzonego przejęcia repozytoriów klientów [1].

Co GitHub zrobił po wykryciu incydentu?

GitHub rotował krytyczne sekrety od 18 do 19 maja, priorytetowo traktując poświadczenia o największym wpływie, analizował logi i monitorował dalszą aktywność [1]. Rozszerzenie zostało usunięte, a urządzenie pracownika odizolowane w ramach reagowania na incydent [1].

26 maja GitHub zarządził dodatkowo rotację klucza podpisującego GitHub Enterprise Server. Administratorzy GHES musieli zrotować klucze GPG, natomiast klienci GitHub Enterprise Cloud nie musieli wykonywać tej procedury [1].

Firma podała, że nie ma dowodów na wpływ na dane przechowywane poza jej wewnętrznymi repozytoriami, w tym na repozytoria, organizacje i przedsiębiorstwa klientów. Zastrzegła jednocześnie, że niektóre wewnętrzne repozytoria mogą zawierać informacje pochodzące od klientów [1].

Jakie wektory ataku przez edytor są znane?

Znane przypadki różnią się punktem wejścia. W sprawie GitHuba wektorem było złośliwe wydanie rozszerzenia z Marketplace [2]. Osobny przypadek opisany przez Sekuraka dotyczył podatności w webowym edytorze VS Code udostępnianym przez GitHuba: samo otwarcie repozytorium mogło umożliwić kradzież tokenu użytkownika [7].

Oba warianty łączy jedno: atakujący nie musi łamać infrastruktury dostawcy, wystarczy mu jedno urządzenie z uprawnieniami do repozytoriów [1][2].

Czego w tej sprawie nie wiadomo?

Publiczny komunikat nie potwierdza scenariusza, w którym pracownik ręcznie kliknął „Zainstaluj”. Nie wiadomo, czy instalacja była ręczna, czy nastąpiła przez aktualizację automatyczną [1].

Brak też potwierdzenia dla przedziału „kilka godzin” między instalacją a dostępem do tysięcy repozytoriów. Komunikat podaje wykrycie 18 maja i rotację sekretów 18–19 maja, ale nie wyznacza takiego okna czasowego [1].

Atrybucję na grupę TeamPCP podają doniesienia medialne, w tym opis żądania 50 tys. USD [5][6]. Nie jest to element pierwotnego komunikatu GitHuba [1]. Liczba 3800 pozostaje bieżącą oceną, a nie wynikiem zamkniętego audytu [1][3].

Jak ograniczyć ryzyko w zespole?

Praktyka, którą polecamy, opiera się na ograniczaniu zakresu zaufania, a nie na zakazie instalowania rozszerzeń.

1. Przypinaj wersje rozszerzeń w ustawieniach zespołu i aktualizuj je świadomie. Wersja 18.95.0 Nx Console była dostępna w Marketplace około 11 minut, więc różnica między wersją sprawdzoną a bieżącą może być krótka [2].
2. Sprawdzaj wydawcę i identyfikator rozszerzenia. W analizowanym przypadku identyfikator to nrwl.angular-console, a wydanie pochodziło z konta strony trzeciej [2].
3. Oddzielaj poświadczenia od środowiska pracy. Tokeny o minimalnym zakresie i krótkim czasie życia ograniczają skutki przejęcia urządzenia. GitHub rotował krytyczne sekrety 18–19 maja, co pokazuje skalę działań po wykryciu [1].
4. Monitoruj nietypową aktywność w repozytoriach. Masowe pobieranie kodu i nietypowe zmiany to sygnały, które GitHub analizował po incydencie [1].
5. Utrzymuj plan rotacji kluczy podpisujących dla środowisk enterprise. 26 maja rotacja klucza GHES objęła administratorów tej wersji [1].

Co to oznacza dla polskich zespołów?

Polskie zespoły korzystają z tych samych łańcuchów zależności co GitHub, tylko na mniejszą skalę. Decyzja o instalacji rozszerzenia zapada w edytorze, a skutki dotyczą całego repozytorium i poświadczeń w środowisku. Dlatego polecamy traktować konfigurację repozytorium, w tym pliki opisujące pracę agentów, jako element polityki bezpieczeństwa, a nie zwykły dodatek. Punkt wyjścia do przeglądu takich plików zebraliśmy w artykule o plikach AGENTS.md w repozytoriach. Szerszy kontekst narzędzi i ich modeli opisuje hub AI do programowania.

Najczęstsze pytania

Czy incydent dotyczył repozytoriów klientów GitHuba?

GitHub podał, że nie ma dowodów na wpływ na dane przechowywane poza jego wewnętrznymi repozytoriami, w tym na repozytoria, organizacje i przedsiębiorstwa klientów. Jednocześnie firma zastrzegła, że niektóre wewnętrzne repozytoria mogą zawierać informacje pochodzące od klientów. Publiczny komunikat nie wskazuje na naruszenie danych klientów, ale nie zamyka tej kwestii bezwarunkowo [1].

Czy zwykła wersja Nx Console jest niebezpieczna?

Opisany problem dotyczy złośliwej wersji 18.95.0 opublikowanej w Marketplace, a nie całego rozszerzenia. Według analizy StepSecurity ta wersja była dostępna około 11 minut i pobierała dodatkowy payload, a OpenVSX nie było objęte tym wydaniem [2]. Przy instalacji sprawdzaj numer wersji i źródło wydania, a aktualizacje rób świadomie [2].

Jak długo złośliwa wersja może być dostępna w Marketplace?

W analizowanym przypadku około 11 minut [2]. To pokazuje, że czas dostępności nie jest zabezpieczeniem: krótkie okno wystarczy, jeśli trafi w urządzenie z szerokimi uprawnieniami. GitHub wykrył kompromitację 18 maja i rotował sekrety 18–19 maja [1], więc reakcja po stronie użytkownika musi być równie szybka.

Czy webowy edytor VS Code też był celem ataków?

Osobny przypadek opisał Sekurak: badacz Ammar Askar znalazł podatność w webowym edytorze VS Code udostępnianym przez GitHuba, w której samo otwarcie repozytorium mogło pozwolić na kradzież tokenu użytkownika [7]. To inny wektor niż złośliwe rozszerzenie, ale skutek jest podobny: przejęcie poświadczeń dających dostęp do repozytoriów.

Źródła

1. Investigation update: GitHub Enterprise Server signing key rotation (The GitHub Blog, 2026)
2. Nx Console VS Code Extension Compromised (StepSecurity, 2026)
3. GitHub confirms breach of 3,800 repos via malicious VSCode extension (BleepingComputer, 2026)
4. Włamanie do GitHuba. Zainfekowane rozszerzenie do VS Code i dostęp do 3800 wewnętrznych repozytoriów (Sekurak, 2026)
5. Zainfekowane rozszerzenie VS Code otworzyło hakerom drzwi do wewnętrznych repozytoriów (Bitcoin.pl, 2026)
6. GitHub potwierdza wyciek 3800 repozytoriów – winowajcą wtyczka VS Code (TeamPCP) (DevStock Academy, 2026)
7. Podatność w webowym VSCode (GitHub) pozwalała przejąć token użytkownika (Sekurak, 2026)