GitHub potwierdza wyciek 3800 repozytoriów – winowajcą wtyczka VS Code

GitHub potwierdził 20 maja 2026, że doszło do wycieku około 3800 wewnętrznych repozytoriów firmy. Wektor jest brutalnie prosty: jeden z pracowników GitHuba zainstalował złośliwą wtyczkę do edytora VS Code i ta wtyczka zrobiła resztę. Za atakiem stoi grupa TeamPCP – ta sama, która dobę wcześniej wypchnęła 314 zainfekowanych paczek do npm. Stawka wyjściowa za wykradziony kod GitHuba na hakerskim forum Breached to 50 tysięcy dolarów. Według firmy dane klientów – kod publiczny i prywatny w organizacjach na GitHub.com – nie są dotknięte. Polskim zespołom DevOps zostaje natomiast jedna konkretna lekcja na dziś.

Co dokładnie się stało

Sprawa rozegrała się w ciągu jednej doby, a jej kluczem nie jest skala wycieku, tylko wektor. Najpierw chronologia, potem komunikat samego GitHuba, a na końcu to, jak złośliwa wtyczka mogła wejść tak głęboko.

Timeline wycieku w 24 godziny

We wtorek 19 maja 2026 TeamPCP wystawiło na hakerskim forum Breached ofertę sprzedaży, w której obiecywało dostęp do “około 4000 prywatnych repozytoriów” zawierających kod źródłowy GitHuba i wewnętrznych organizacji firmy. Grupa oferowała przy tym próbki kupującym i wprost zaznaczała, że nie traktuje sprzedaży jako ransomware. Schemat opisany na forum brzmiał inaczej: jeden kupiec dostaje pakiet, dane idą do zniszczenia po stronie sprzedającego, a jeśli kupca nie ma, lecą publicznie. Dwadzieścia cztery godziny później, w środę 20 maja, GitHub potwierdził naruszenie. W efekcie faktyczna liczba okazała się trochę niższa niż w ofercie – około 3800 wewnętrznych repozytoriów.

Co mówi GitHub

Komunikat firmy jest dość ostrożny i zawężający zakres. Cytujemy bezpośrednio.

“Nasza obecna ocena wskazuje, że aktywność polegała wyłącznie na wyprowadzeniu wewnętrznych repozytoriów GitHuba” – oświadczenie GitHub, 20 maja 2026 (tłumaczenie własne).

Druga część oświadczenia precyzuje, czego naruszenie nie obejmuje, i to właśnie ten fragment będzie najważniejszy dla polskiej firmy korzystającej z GitHub Enterprise.

“Na obecną chwilę nie mamy dowodów na wpływ na dane klientów przechowywane poza wewnętrznymi repozytoriami GitHuba – czyli organizacje, instancje enterprise i repozytoria naszych klientów” – oświadczenie GitHub, 20 maja 2026 (tłumaczenie własne).

Najważniejsze słowo to “internal”. Według firmy wyciek obejmuje wyłącznie wewnętrzne repozytoria GitHuba jako organizacji – czyli kod produktu, kod platformy, dokumenty firmowe. Nie obejmuje natomiast publicznego ani prywatnego kodu klientów hostowanego na GitHub.com. Z perspektywy polskiej firmy używającej GitHub Enterprise to ważne rozróżnienie. Stan z 20 maja jest taki, że pliki Twojej organizacji nie zostały dotknięte.

Wtyczka jako wektor

Klucz tej sprawy nie tkwi jednak w skali, tylko w wektorze. GitHub przyznał, że jeden z pracowników zainstalował złośliwą wtyczkę do edytora VS Code i że ta wtyczka umożliwiła wyprowadzenie wewnętrznych repozytoriów firmy. Konkretny mechanizm techniczny nie został publicznie ujawniony. Firma usunęła wtyczkę z oficjalnego marketplace, ale jej nazwy nie podała. Dlatego pojawia się dość niewygodne pytanie: który polski deweloper ma w tej chwili u siebie tę samą wtyczkę i po prostu o tym nie wie?

TeamPCP – ta sama grupa co dobę wcześniej

Atak na GitHuba nie jest oderwanym incydentem. To druga, w 24 godziny, akcja tej samej grupy, wpisująca się w szerszy wzorzec ataków przez pluginy. Warto połączyć kropki.

Dwa ataki w 24 godziny

To nie jest pojedynczy incydent. TeamPCP w ciągu jednej doby zaatakowali dwa filary nowoczesnej pracy programisty. Najpierw, w nocy z 18 na 19 maja, wypchnęli 314 zainfekowanych paczek do rejestru npm w ramach kampanii Mini Shai-Hulud. Opisywaliśmy to w artykule Atak na npm: 314 paczek zainfekowanych – cel Claude Code. Dobę później wyciekły wewnętrzne repo GitHuba. Te dwie sprawy łączy nie tylko sygnatura tej samej grupy. Łączy je wzorzec: zaatakować narzędzia, których programista używa codziennie, i wykraść z nich poświadczenia, które otwierają kolejne drzwi.

Wzorzec “plugin jako koń trojański”

Ataki przez wtyczki rosną w branży od ponad roku. Co więcej, w maju opisywaliśmy trojana w pluginie do Obsidiana, w którym celem byli pracownicy z sektora finansowego i krypto. Mechanizm jest niemal identyczny: pracownik instaluje pozornie niewinne rozszerzenie, a złośliwy kod uruchamia się przy pierwszej okazji – przy starcie edytora, przy otwarciu vaulta, przy zatrzymanej sesji. Z perspektywy hakera to natomiast genialnie tanie wejście. Pracownik sam, własnoręcznie omija każdy firewall i antywirus, ponieważ instaluje wtyczkę dobrowolnie z zaufanego marketplace’u.

Dlaczego marketplace to nie sandbox

Tu pojawia się niewygodna prawda o ekosystemie wtyczek. Microsoft VS Code Marketplace, podobnie jak npm i Community Plugins Obsidiana, opiera się głównie na zaufaniu społecznościowym. Audyt automatyczny istnieje, ale nie wychwytuje wszystkiego. Wystarczy, że złośliwa logika uruchamia się dopiero po dłuższym czasie albo że autor wtyczki ma legitymną historię i potem podmienia ją na zainfekowaną wersję. Polski dev, który ma w VS Code dziesięć wtyczek od mało znanych autorów, ma realne ryzyko, że choć jedna z nich kiedyś zostanie przejęta lub zainfekowana.

Co to znaczy dla polskich developerów

Z tego ataku da się wyciągnąć trzy konkretne lekcje, które polska firma może wdrożyć już dziś, bez dodatkowych narzędzi ani konsultantów.

Lekcja numer jeden: audyt rozszerzeń

Po historii z GitHubem warto zrobić w poniedziałek konkretną rzecz. Najpierw otwórz VS Code, wejdź w listę zainstalowanych rozszerzeń i przejrzyj je krytycznym okiem. Każde rozszerzenie od autora bez weryfikacji, bez stałej historii commitów, z małą liczbą instalacji – jest kandydatem do usunięcia. Im więcej rozszerzeń, tym większe ryzyko, że jedno z nich będzie tym, które GitHub teraz zdejmuje z marketplace. Co więcej, dotyczy to też Cursora, Zed-a, Windsurfa i każdego innego forka, który dziedziczy ekosystem rozszerzeń VS Code.

Lekcja numer dwa: rotacja tokenów i sekrety

Skoro złośliwa wtyczka u pracownika GitHuba doprowadziła do wyprowadzenia wewnętrznych repozytoriów firmy, ta sama klasa ataku może sięgnąć po Twoje poświadczenia albo Twój kod. W praktyce oznacza to konkretny ruch dla polskiej firmy. Zrotuj wszystkie tokeny GitHub Personal Access Tokens używane przez deweloperów. Sprawdź uprawnienia tokenów do organizacji – czy faktycznie wszyscy potrzebują pełnego scope, czy może wystarczy ograniczony zakres. Wymuś GitHub fine-grained tokens zamiast classic. Włącz wymuszanie MFA w całej organizacji, najlepiej z kluczem sprzętowym (YubiKey, SoloKey) zamiast aplikacji TOTP.

Lekcja numer trzy: segregacja workspace’u

Najbardziej zaawansowany ruch to oddzielenie środowiska, w którym instalujesz nowe rozszerzenia eksperymentalne, od środowiska, w którym pracujesz z kodem produkcyjnym. VS Code od dawna pozwala na to przez profile – możesz mieć profil “production” z minimalnym setem zaufanych rozszerzeń, a obok niego profil “experiments” z eksperymentalną zawartością. Dev Containers mogą dodatkowo ograniczyć część ekspozycji środowiska pracy, ale nie zastępują audytu rozszerzeń. Dla polskiej firmy z wymaganiami RODO albo compliance branżowym to przestaje być zabawka. W rezultacie staje się standardem, który właśnie zaczyna się opłacać.

Pierwsza Misja AI · Kodożercy

Rozumiesz zagrożenia AI, gdy rozumiesz jak naprawdę działa.

Kurs Pierwsza Misja AI ma dedykowaną lekcję o ciemnej stronie AI: halucynacje, deepfakes, manipulacja. Zanim zaczniesz się bać – zacznij rozumieć.

Poznaj pełny program →

Podsumowanie

Wyciek GitHuba pokazuje coś, co programiści wiedzą od dawna, ale rzadko traktują serio. Marketplace wtyczek to nie sandbox, a codzienny rytuał “zainstaluję ten plugin, bo wygląda przydatnie” jest dla atakującego najtańszym wejściem do firmy. TeamPCP w ciągu jednej doby uderzyli w dwa zaufane kanały: npm i GitHub jako firmę. Dane klientów na GitHub.com są na razie bezpieczne, ale lekcja zostaje. Polska firma, która do końca tygodnia zrobi audyt rozszerzeń, rotację tokenów i włączy klucze sprzętowe dla MFA, istotnie ogranicza ekspozycję na ten typ ataku. Druga taka okazja może już nie wymagać błędu pracownika – może wystarczyć dobrze zaplanowana zainfekowana paczka.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.