Hugging Face jako ukryty serwer malware: jak działa atak js-logger-pack na deweloperów AI

Pakiet npm o nazwie js-logger-pack po cichu pobiera plik z Hugging Face zaraz po instalacji w projekcie. Plik nazywa się MicrosoftSystem64, podszywa się pod komponent systemowy Windowsa, dodaje wpis do Harmonogramu zadań i zaczyna logować klawiaturę oraz schowek. JFrog opisał ten atak 23 kwietnia 2026, a sygnał o szerszym problemie pojawia się na Reddicie i w branży niemal codziennie. Co ciekawe, malware na Hugging Face nie jest już wgrywany jako “złośliwy model”. Atakujący wykorzystuje platformę jako sieć dostarczania (CDN, czyli sieć rozproszonych serwerów). Niektóre prywatne zbiory danych pełnią dodatkowo rolę magazynu na skradzione informacje. Dokładnie ten ruch powinien zaalarmować każdego, kto buduje workflow AI z modelami z HF. Pokazujemy, co dzieje się automatycznie zaraz po infekcji, co wymaga komendy operatora oraz jak zabezpieczyć swoje projekty AI przed kolejnymi wariantami tego ataku.

Jak działa atak js-logger-pack krok po kroku

Atak zaczyna się od zwykłego npm install w projekcie, który ma pakiet js-logger-pack w zależnościach. Wszystko dalej dzieje się bez interakcji użytkownika. To jak zamówienie paczki kurierskiej, w której pod warstwą papieru pakownego jest druga paczka, a w niej jeszcze jedna. Każda warstwa wygląda na bezpieczną.

Postinstall hook uruchamia pobranie w tle

JFrog zidentyfikował złośliwe wersje pakietu od 1.1.0 do 1.1.27. Każda z nich ma w package.json haczyk postinstall, czyli skrypt uruchamiany po pomyślnej instalacji. Skrypt cicho pobiera plik z repozytorium Lordplay/system-releases na Hugging Face. To repozytorium powstało 19 kwietnia 2026 i wygląda jak zwykły dataset, ale w środku ma cztery binarki, jedną na każdą platformę.

Dlaczego ten ruch jest niebezpieczny? Ponieważ npm audit nie sprawdza zewnętrznych pobrań w haczyku postinstall. Dla zwykłego dewelopera to po prostu instalacja paczki, która “nic ciekawego nie robi”. W tle natomiast leci cała sekwencja akcji.

Cztery binarki w jednym repozytorium Hugging Face

Repozytorium Lordplay/system-releases zawiera cztery pliki nazwane MicrosoftSystem64 z różnymi rozszerzeniami. Każdy obsługuje inną kombinację systemu i architektury procesora. Po pobraniu wszystkie cztery zawierają identyczny ładunek. Hash osadzonego skryptu JavaScript to 1c83019b52be6da9583d28fe934441a74eacef0cd7dbb9d71017122de6fe7cfc, co potwierdza, że jest to ten sam implant skompilowany dla różnych platform.

Nazwa MicrosoftSystem64 to klasyczny ruch maskujący. Dla Windowsa wygląda na komponent systemowy. Dla użytkownika macOS – na coś podejrzanego, ale i tak nie tak alarmującego, jak gdyby plik nazywał się “stealer.exe”.

Co więcej, w metadanych commitów związanych z repozytorium Lordplay/system-releases pojawiło się nazwisko Josha Stevensa – VP Engineering w Polymarket i znanego dewelopera open source. JFrog wyraźnie zaznacza, że te metadane nie dowodzą jego udziału w ataku. To raczej klasyczny ruch, w którym ofiara widzi znajome nazwisko w historii repozytorium i mniej waha się przed kliknięciem npm install. Typosquatting (rejestracja paczki o nazwie zbliżonej do popularnej) idzie tu w parze z podszywaniem się pod autora.

Persistencja – Harmonogram zadań, LaunchAgent i systemd

Po uruchomieniu binarka rejestruje się w systemie tak, żeby wstawała przy każdym starcie. W Windowsie tworzy zaplanowane zadanie \MicrosoftSystem64 oraz wpis w rejestrze pod kluczem Run. Wersja dla macOS instaluje LaunchAgent o nazwie com.launchkeeper.MicrosoftSystem64.plist. Z kolei na Linuksie wybór pada na jednostkę użytkownika systemd albo plik autostartu zgodny ze standardem XDG.

Mianowicie atak nie wymaga uprawnień administratora – korzysta wyłącznie z mechanizmów dostępnych dla zwykłego użytkownika. To dobra wiadomość, jeśli ktoś szuka, gdzie sprawdzić infekcję. Zła – bo nie zatrzymują tego standardowe zabezpieczenia, które wymagają uprawnień roota dla globalnej persistencji. Podobny mechanizm omawialiśmy szerzej w analizie bezpieczeństwa serwerów MCP w agentach AI, gdzie wzorzec “ufnej zależności” rozkładał całą architekturę agenta.

Co dokładnie kradnie MicrosoftSystem64

Po włączeniu binarka łączy się z serwerem 195.201.194.107:8010 przez WebSocket oraz HTTP. Dalej pracuje jak typowy infostealer (program kradnący dane logowania), ale z istotnym podziałem ról. Część zadań startuje w tle natychmiast, część dopiero gdy operator przyśle komendę przez ten kanał.

Automatycznie: keylogger, schowek i wstępny zwiad

Zaraz po starcie malware na Hugging Face uruchamia natywne haczyki klawiatury każdego systemu, monitoruje schowek oraz wysyła do operatora pakiet ze zwiadem o systemie i środowisku użytkownika. Te trzy rzeczy lecą same z siebie, bez interakcji z atakującym. Jeśli kopiujesz hasło z menedżera haseł i wklejasz w przeglądarce, malware przechwyci je w ułamku sekundy między tymi dwoma akcjami.

Wyobraź sobie, że ktoś stoi za Twoim ramieniem przez cały dzień i notuje każde Twoje wciśnięcie klawisza. Tyle dzieje się od razu, bez decyzji atakującego. Reszta przychodzi dopiero, gdy ktoś po drugiej stronie kanału stwierdzi, że warto się Tobą zająć.

Na komendę: Telegram, portfele krypto i skanowanie plików

Druga warstwa kradzieży uruchamia się dopiero, gdy operator wyśle konkretne polecenie. JFrog wymienia w protokole zadań kilka takich poleceń. Rekurencyjne skanowanie katalogów pod kątem haseł, przegląd tdata Telegrama Desktop (zawiera klucze do sesji), kopiowanie portfeli kryptowalut oraz wgrywanie wybranych folderów do prywatnych zbiorów danych na Hugging Face. To z jednej strony dobra wiadomość, bo atakujący nie zdąży jednocześnie obrobić tysięcy ofiar. Z drugiej zła – jeśli wybierze właśnie Twój komputer jako interesujący, dostaje narzędzie do bardzo dokładnej kradzieży na żądanie.

Dla osoby budującej automatyzacje AI to oznacza realny problem. Klucze do OpenAI, Anthropic, n8n Cloud czy AWS w .bashrc, .zshrc albo plikach konfiguracyjnych są w zasięgu, gdy tylko operator zechce po nie sięgnąć. Co więcej, część skradzionych informacji nie ląduje na własnym serwerze atakującego, tylko w prywatnych repozytoriach na Hugging Face. Innymi słowy – platforma jest jednocześnie kanałem dystrybucji oraz schowkiem na skradzione dane.

Dlaczego Hugging Face stał się idealnym schowkiem

Hugging Face to dziś jedna z najbardziej zaufanych platform w ekosystemie AI. Dla deweloperów to standardowe miejsce, skąd pobiera się modele językowe, datasety, narzędzia. Dla narzędzi bezpieczeństwa korporacyjnego ruch do huggingface.co nie wygląda podejrzanie, bo jest częścią normalnego workflow każdego zespołu pracującego z AI. Właśnie dlatego malware na Hugging Face przechodzi obok firewalla bez niczyjego zdziwienia.

100 złośliwych modeli wcześniej – kontekst 2024

Problem nie jest nowy. JFrog już w lutym 2024 opisał około 100 złośliwych modeli AI hostowanych na Hugging Face. Najczęstszą techniką była niebezpieczna deserializacja w PyTorch, gdzie złośliwy plik modelu używał metody __reduce__ Pythona, żeby uruchomić dowolny kod podczas wczytywania. Skutek? Reverse shell na maszynie ofiary, czyli tylne drzwi pozwalające atakującemu zdalnie sterować komputerem.

Dwa lata później wektor ataku ewoluował. Nikt już nie ukrywa kodu w samym modelu. Atakujący traktuje Hugging Face jak GitHuba do plików binarnych – hostuje tam dowolne pliki, a złośliwy kod uruchamia z poziomu menedżera pakietów innej technologii (npm, pip, gem). Hugging Face staje się przezroczystą warstwą dystrybucji, która nie wygląda podejrzanie ani dla użytkownika, ani dla skanerów.

Z perspektywy security to przesunięcie ciężaru. Dawniej szukaliśmy złośliwych modeli AI. Dziś szukamy złośliwych zależności w menedżerach pakietów, które używają zaufanych platform AI jako CDN.

Skanery HF nie patrzą tak głęboko na binarki w datasetach

Hugging Face ma od 2024 roku skaner ClamAV i Pickle Scanner, który łapie klasyczne złośliwe modele Python. Natomiast surowe pliki wykonywalne ELF, Mach-O i PE w datasetach dostają tylko podstawowe sprawdzenie sygnatur antywirusowych. Jeśli atakujący zna techniki obfuskacji binarki, jego ładunek przejdzie przez skanowanie. Dlatego widzimy coraz więcej kampanii, które celowo używają HF jako repozytorium, omijając standardowe rejestry malware.

To jak zostawienie torby z narzędziami w szatni siłowni. Recepcjonistka rzuca okiem czy nie ma w niej noża, ale nie sprawdza, czy klucz nasadowy w środku nie jest kluczem nasadowym do otwierania szafek innych klientów.

Kurs n8n 2.0 · Kodożercy

Ile godzin tygodniowo tracisz na powtarzalne zadania?

n8n pozwala zautomatyzować to co robisz ręcznie – przesyłanie danych, powiadomienia, raporty. Kurs n8n 2.0 na Kodożercach pokaże Ci jak, krok po kroku, bez pisania kodu.

Sprawdź kurs n8n 2.0 →

Jak zabezpieczyć swoje projekty AI przed takimi atakami

Zacznij od czterech kroków, które możesz zrobić jeszcze dziś. Każdy zamyka inną furtkę, którą wykorzystał js-logger-pack.

Sprawdź, czy nie jesteś już na liście ofiar

1. Audyt zależności i dysku. Najpierw zajrzyj do swojego package-lock.json pod kątem js-logger-pack w wersjach od 1.1.0 do 1.1.27. Jeśli pakiet pojawia się w Twoim projekcie – usuń go, ponownie zainstaluj zależności i przeanalizuj, co mogło zostać skradzione w międzyczasie. Sprawdź obecność pliku MicrosoftSystem64 na dysku oraz zaplanowanego zadania o tej samej nazwie. Czy już to zrobiłeś?

2. Monitoring ruchu sieciowego. Domyślny serwer kontroli 195.201.194.107 jest hostowany w niemieckim centrum danych Hetzner. Jeśli Twój komputer odzywa się tam co kilka minut bez powodu, to pierwszy sygnał. Narzędzia takie jak Little Snitch na macOS, glasswire na Windowsie albo zwykły iftop na Linuksie pokażą takie połączenia.

Skonfiguruj npm i menedżer sekretów raz a dobrze

3. --ignore-scripts jako domyślne ustawienie npm dla projektów, w których nie ufasz w 100% zależnościom. Pełna komenda to npm config set ignore-scripts true. Dzięki temu haczyki postinstall nie uruchomią się automatycznie. Niektóre legalne pakiety wymagają ich do działania, ale w większości projektów workflow nic nie traci. To prosty filtr przeciwko najpopularniejszemu wektorowi ataku w npm.

4. Klucze API w menedżerze sekretów, nie w .env ani .bashrc. 1Password CLI, Bitwarden Secrets Manager albo HashiCorp Vault – każdy z nich pozwala wstrzykiwać sekrety w chwili uruchomienia tylko do procesu, który ich potrzebuje. Plik .env w repozytorium projektu to dziś ten sam poziom ryzyka, co hasło zapisane na żółtej kartce na monitorze.

Co dalej? Każda z tych zmian zajmuje 15-30 minut, a razem znacząco utrudniają życie atakującym, którzy idą drogą supply chain w npm. Dlatego warto zrobić to wszystko jednorazowo, niż czekać, aż kolejny wariant js-logger-pack przyjdzie pod inną nazwą.

FAQ – najczęstsze pytania o malware na Hugging Face

Czy mam usunąć modele, które ostatnio pobrałem?

Nie wszystkie. Modele w formacie safetensors albo PyTorch od dużych, weryfikowanych autorów (Mistral, Meta, Google, Anthropic) niosą zwykle dużo mniejsze ryzyko. Mimo to nadal sprawdzaj autora, format i pliki towarzyszące. Najgorsze przypadki to datasety z plikami wykonywalnymi (.exe, ELF bez rozszerzenia, Mach-O), które ktoś dorzucił “przy okazji”. To one są wektorem ataku, a nie sam fakt pobierania z Hugging Face.

Jak rozpoznać, czy mój komputer jest zainfekowany?

Sprawdź trzy miejsca. W Windowsie: zaplanowane zadania (Get-ScheduledTask -TaskName "*MicrosoftSystem64*") oraz klucz rejestru HKCU\Software\Microsoft\Windows\CurrentVersion\Run. Dla macOS: zawartość ~/Library/LaunchAgents/ pod kątem plików o nazwie zawierającej launchkeeper. Z kolei na Linuksie: systemctl --user list-unit-files oraz ~/.config/autostart/. Jeśli znajdziesz MicrosoftSystem64 – jesteś zainfekowany. Pierwszą rzeczą po wykryciu jest zmiana wszystkich kluczy API i haseł, które przechodziły przez ten komputer.

Czy npm audit wystarczy żeby się zabezpieczyć?

Niestety nie. npm audit sprawdza znane luki bezpieczeństwa w katalogu CVE (oficjalna baza ujawnionych podatności), ale nie analizuje skryptów postinstall ani zewnętrznych pobrań. Js-logger-pack przeszedł audit z wynikiem “0 vulnerabilities” przez pierwsze tygodnie. Dlatego potrzebne są dodatkowe warstwy: socket.dev, snyk, własne reguły CI/CD oraz --ignore-scripts dla nieznanych pakietów.

Podsumowanie

Atak js-logger-pack to nie kolejna nudna luka w niszowym pakiecie. To pokazanie nowego mechanizmu, w którym napastnik używa zaufanej platformy AI jako serwera dystrybucji oraz magazynu skradzionych danych. Sygnał dla osoby budującej automatyzacje w n8n czy projekty z modelami AI jest prosty. Mianowicie malware na Hugging Face przestał być teorią z raportów – przyszedł w zwykłym pakiecie z npm i jutro przyjdzie pod inną nazwą. Zacznij od --ignore-scripts, audytu zaplanowanych zadań na swoim komputerze i przeniesienia kluczy API z .env do menedżera sekretów. Te trzy kroki zamykają większość drogi atakującym.

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.