Wyciek kodu Claude Code wykorzystany do dystrybucji malware na GitHubie

securitybeztabu.pl 1 dzień temu

Wprowadzenie do problemu / definicja

Wyciek kodu źródłowego Claude Code gwałtownie przestał być wyłącznie problemem związanym z błędem publikacji i ochroną własności intelektualnej. W ciągu krótkiego czasu incydent został wykorzystany przez cyberprzestępców do przygotowania kampanii malware wymierzonej w deweloperów, administratorów i użytkowników poszukujących nieoficjalnych wersji narzędzia.

Mechanizm ataku był prosty, ale skuteczny: po ujawnieniu fragmentów wewnętrznego kodu zaczęły pojawiać się fałszywe repozytoria GitHub oraz archiwa podszywające się pod „odblokowane” wydania Claude Code. W rzeczywistości zawierały one złośliwe oprogramowanie, którego celem była kradzież danych i przejęcie dostępu do zainfekowanych systemów.

W skrócie

31 marca 2026 roku do publicznego obiegu trafił kod źródłowy Claude Code w wyniku błędu pakietowania wydania. Ujawniony materiał obejmował około 513 tys. linii nieobfusowanego kodu TypeScript w 1906 plikach.

Wkrótce po wycieku badacze bezpieczeństwa zaobserwowali kampanię wykorzystującą fałszywe repozytoria GitHub. Jedno z nich promowało archiwum zawierające droppera napisanego w Rust, który po uruchomieniu instalował infostealera Vidar oraz komponent GhostSocks odpowiedzialny za pośredniczenie w ruchu sieciowym.

wyciek wynikał z błędu procesu publikacji, a nie z klasycznego włamania,
atakujący gwałtownie wykorzystali wysokie zainteresowanie tematem,
fałszywe repozytoria oferowały rzekomo „odblokowane” wersje narzędzia,
kampania była wymierzona przede wszystkim w stacje robocze deweloperów.

Kontekst / historia

Źródłem problemu nie był kompromis infrastruktury, ale błąd release engineering. Do jednego z pakietów npm został dołączony plik mapy źródłowej, który umożliwił rekonstrukcję wewnętrznego kodu aplikacji po stronie klienta. Zdarzenie zostało zauważone 31 marca 2026 roku i bardzo gwałtownie stało się głośne w środowisku technologicznym.

Ze względu na rozpoznawalność Claude Code oraz duże zainteresowanie sprawą materiał zaczął błyskawicznie krążyć w serwisach społecznościowych i repozytoriach kodu. To stworzyło idealne warunki dla przestępców: wysoki wolumen wyszukiwań, ciekawość użytkowników oraz skłonność części osób do pobierania nieoficjalnych narzędzi obiecujących brak limitów lub dostęp do funkcji premium.

Co istotne, już wcześniej obserwowano kampanie podszywające się pod instalatory Claude Code. Najnowszy incydent zwiększył jednak ich wiarygodność, ponieważ atakujący mogli odwołać się do prawdziwego wycieku i budować przekaz oparty na autentycznym wydarzeniu.

Analiza techniczna

Techniczna przyczyna wycieku była związana z publikacją artefaktu debugowego w paczce npm. Do wydania dołączono plik .map, który pozwolił odtworzyć znaczną część nieobfusowanego kodu TypeScript. Choć takie pliki są przydatne podczas debugowania, w środowisku produkcyjnym mogą ujawniać strukturę aplikacji, nazwy modułów, logikę działania oraz szczegóły procesu budowania.

Po ujawnieniu materiału atakujący wdrożyli klasyczny model oportunistyczny. Najpierw skopiowali i zmirrorowali opublikowany kod, następnie utworzyli repozytoria podszywające się pod autentyczne lub ulepszone wersje narzędzia, a później dodali do sekcji wydań złośliwe archiwa. Całość została opisana w sposób zwiększający widoczność w GitHubie i wyszukiwarkach.

Jedno z obserwowanych repozytoriów było reklamowane jako „Leaked Claude Code” i sugerowało dostęp do wersji z odblokowanymi możliwościami klasy enterprise oraz bez limitów wiadomości. Był to typowy zabieg socjotechniczny, łączący temat wycieku, ekskluzywności i obejścia ograniczeń licencyjnych.

Złośliwe archiwum zawierało plik wykonywalny ClaudeCode_x64.exe, opisany jako dropper napisany w Rust. Po uruchomieniu miał instalować dwa główne komponenty:

Vidar – infostealer służący do kradzieży haseł, ciasteczek sesyjnych, danych przeglądarek i informacji z portfeli kryptowalutowych,
GhostSocks – narzędzie umożliwiające proxyfikację ruchu sieciowego, wspierające ukrywanie aktywności lub dalsze wykorzystanie zainfekowanego hosta.

Badacze odnotowali także pojawienie się więcej niż jednej wersji złośliwego archiwum w krótkim odstępie czasu. Może to świadczyć o aktywnym rozwijaniu kampanii, testowaniu skuteczności infekcji oraz przygotowaniu zapasowych kopii repozytoriów na wypadek usunięcia części z nich przez platformę.

Konsekwencje / ryzyko

Największe ryzyko dotyczy użytkowników pracujących na stacjach roboczych z dostępem do systemów produkcyjnych, repozytoriów kodu, narzędzi CI/CD, chmury oraz kluczy API. jeżeli taki host zostanie zainfekowany przez infostealera, skutki mogą wykraczać daleko poza pojedynczą maszynę.

kradzież poświadczeń do GitHub, GitLab, VPN i usług chmurowych,
przejęcie aktywnych sesji z przeglądarek,
wyciek sekretów z menedżerów haseł i narzędzi developerskich,
dalszy ruch lateralny w infrastrukturze organizacji,
wykorzystanie hosta jako węzła pośredniczącego w kolejnych atakach.

Incydent pokazuje również, iż choćby wyciek ograniczony pozornie do kodu źródłowego może gwałtownie przekształcić się w realne zagrożenie operacyjne. Sama publikacja kodu nie musiała oznaczać bezpośredniego ujawnienia danych klientów, ale stworzyła bardzo silny pretekst socjotechniczny, który zwiększył skuteczność dystrybucji malware.

Dodatkowym problemem pozostaje ryzyko supply-chain. Zespoły, które pobierają narzędzia z niezweryfikowanych forków lub uruchamiają popularne archiwa znalezione w trendujących repozytoriach, narażają się jednocześnie na malware i kompromitację łańcucha dostaw oprogramowania.

Rekomendacje

Organizacje oraz użytkownicy indywidualni powinni traktować każdą ofertę typu „leak”, „enterprise unlocked” czy „bez limitów” jako potencjalnie złośliwą. W praktyce oznacza to konieczność konsekwentnego korzystania wyłącznie z oficjalnych kanałów dystrybucji oraz wdrożenia dodatkowych zabezpieczeń na stacjach developerskich.

pobierać oprogramowanie wyłącznie z oficjalnych źródeł producenta,
blokować uruchamianie niepodpisanych binariów z katalogów pobrań i archiwów,
monitorować stacje robocze pod kątem nietypowych plików EXE, dropperów Rust i zachowań charakterystycznych dla infostealerów,
rotować tokeny, klucze API i poświadczenia w razie podejrzenia uruchomienia nieautoryzowanego instalatora,
wymuszać ponowne logowanie do systemów krytycznych po potencjalnym incydencie,
wdrożyć EDR lub XDR z detekcjami dla Vidar, loaderów i narzędzi proxy,
ograniczać uprawnienia lokalne na stacjach deweloperskich,
segmentować dostęp do CI/CD, rejestrów pakietów i środowisk chmurowych,
walidować integralność artefaktów i stosować polityki allowlist dla źródeł instalacji,
wykluczać pliki .map oraz artefakty debugowe z publicznych paczek produkcyjnych.

Z perspektywy dostawców systemu incydent podkreśla znaczenie automatyzacji procesu publikacji, skanowania artefaktów przed wydaniem oraz weryfikowania, czy do paczek nie trafiają zasoby wewnętrzne, debugowe lub nieprzeznaczone do ujawnienia.

Podsumowanie

Wyciek kodu Claude Code stał się przykładem tego, jak gwałtownie błąd publikacji może zostać wykorzystany w aktywnej kampanii malware. Ujawnione pliki źródłowe nie były jedynie problemem wizerunkowym i technologicznym, ale posłużyły jako skuteczna przynęta do infekowania użytkowników poprzez fałszywe repozytoria na GitHubie.

Dla zespołów bezpieczeństwa i działów IT to ważne ostrzeżenie: współczesne incydenty mają często charakter kaskadowy i przechodzą od błędu release engineering do zagrożeń operacyjnych. Najlepszą obroną pozostaje ścisła kontrola źródeł instalacji, ochrona stacji developerskich oraz szybka reakcja na wszelkie sygnały kompromitacji poświadczeń lub sesji.