Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania pozostają jednym z najgroźniejszych zagrożeń dla organizacji rozwijających aplikacje w oparciu o komponenty open source. Najnowszy incydent związany z pakietami MemTensor pokazuje, że przejęcie zaufanego procesu publikacji może zostać wykorzystane do dystrybucji wieloplatformowego malware kradnącego poświadczenia.
W opisywanym przypadku złośliwe wersje pojawiły się równolegle w dwóch popularnych ekosystemach: npm oraz PyPI. Taki scenariusz znacząco zwiększa zasięg kampanii i utrudnia szybkie ograniczenie skutków kompromitacji, szczególnie w środowiskach developerskich i CI/CD.
W skrócie
Badacze bezpieczeństwa wykryli złośliwe wersje legalnych pakietów powiązanych z MemTensor. W npm problem dotyczył pakietu @memtensor/memos-cloud-openclaw-plugin w wersjach 0.1.21, 0.1.23 i 0.1.25, natomiast w PyPI zagrożona była wersja 2.0.34 pakietu MemoryOS.
- Ładunek uruchamiał implant napisany w Go, określany jako
sckit. - Malware działał na Windowsie, Linuksie i macOS.
- Celem były sekrety z maszyn deweloperskich oraz środowisk CI/CD.
- Zagrożone były tokeny do rejestrów pakietów, repozytoriów kodu, usług chmurowych, klucze prywatne i zmienne środowiskowe.
- Analizy wskazywały również na potencjał dalszego rozprzestrzeniania poprzez workflow GitHub Actions i kolejne pakiety.
Kontekst / historia
Incydent został ujawniony 23 września 2026 roku, gdy zespoły badawcze opisały kompromitację legalnych artefaktów MemTensor. Kluczowe jest to, że atak nie opierał się na publikacji fałszywych bibliotek typu typosquatting, lecz na złośliwych wydaniach prawdziwych projektów, które wcześniej cieszyły się zaufaniem użytkowników.
Taki model działania jest szczególnie niebezpieczny, ponieważ omija podstawowe mechanizmy ostrożności stosowane przez programistów. Zaufane nazwy pakietów, automatyczne aktualizacje zależności i integracja z pipeline’ami budowania sprawiają, że złośliwy kod może zostać uruchomiony bez wzbudzania natychmiastowych podejrzeń.
Incydent wpisuje się w szerszy trend ataków wymierzonych w narzędzia deweloperskie, platformy CI/CD i ekosystem open source. Wraz ze wzrostem wykorzystania bibliotek wspierających aplikacje AI oraz złożonych workflow automatyzacji, komponenty obsługujące pamięć, kontekst i integracje pomocnicze stają się coraz atrakcyjniejszym wektorem ataku.
Analiza techniczna
Z dostępnych analiz wynika, że złośliwe wydania zawierały ukryty binarny ładunek napisany w języku Go. W wariancie npm implant był uruchamiany przy starcie gatewaya agenta oraz podczas obsługi zdarzeń związanych z przywoływaniem pamięci, co oznaczało działanie w kontekście procesu mającego dostęp do danych wejściowych użytkownika i wrażliwych zmiennych środowiskowych.
W przypadku pakietu dostępnego w PyPI aktywacja następowała już przy imporcie modułu memos. Taki sposób wykonania zwiększał ryzyko w środowiskach testowych, developerskich i automatycznych pipeline’ach, ponieważ sam import biblioteki mógł wystarczyć do uruchomienia złośliwego kodu.
Implant sckit miał zbierać szeroki zestaw artefaktów uwierzytelniających. Wśród potencjalnych celów znajdowały się pliki konfiguracyjne rejestrów pakietów, tokeny GitHub i GitLab, dane dostępowe do AWS, sekrety z systemów typu Vault, klucze SSH, tokeny JWT, a także zmienne środowiskowe zawierające hasła, klucze API, ciasteczka sesyjne i connection stringi.
Analizy wskazują również, że atakujący mogli pozyskać tokeny publikacyjne z pipeline’ów opartych o GitHub Actions. Oznaczałoby to kompromitację procesu CI/CD, a nie tylko pojedynczej stacji roboczej maintenera. Jeśli sekret publikacyjny był udostępniany w niewłaściwie zabezpieczonym kroku workflow, mógł zostać wykorzystany do opublikowania złośliwych wersji w oficjalnych rejestrach.
Najbardziej niepokojący jest jednak potencjał robakowy kampanii. Według badaczy sckit zawierał mechanizmy umożliwiające dalsze rozprzestrzenianie się przez publikację kolejnych pakietów npm i PyPI oraz modyfikację workflow GitHub Actions. To oznacza przejście od klasycznego stealera do aktywnego zagrożenia supply chain zdolnego do wtórnych kompromitacji.
Konsekwencje / ryzyko
Dla organizacji wykorzystujących zagrożone pakiety skutki mogą wykraczać daleko poza pojedynczą infekcję hosta. Jeśli złośliwa wersja została uruchomiona na stacji deweloperskiej, napastnik mógł uzyskać dostęp do tokenów publikacyjnych, kluczy chmurowych, repozytoriów kodu i innych systemów wewnętrznych.
Jeszcze groźniejszy scenariusz dotyczy środowisk CI/CD. Runner wykonujący testy lub build z podatną zależnością mógł ujawnić sekrety używane tymczasowo w pipeline’ach, takie jak tokeny wdrożeniowe, dane publikacyjne czy krótkotrwałe poświadczenia chmurowe. Nawet krótkie uruchomienie złośliwego pakietu należy więc traktować jako potencjalne naruszenie poufności.
Ryzyko obejmuje także wtórne kompromitacje. Przejęte poświadczenia do npm, PyPI, GitHub lub GitLab mogą zostać wykorzystane do publikacji kolejnych złośliwych wersji innych projektów, modyfikowania workflow automatyzacji, podmiany wydań albo uzyskania dostępu do prywatnych repozytoriów.
Rekomendacje
Organizacje powinny w pierwszej kolejności ustalić, czy w ich środowiskach występowały wersje 0.1.21, 0.1.23 lub 0.1.25 pakietu @memtensor/memos-cloud-openclaw-plugin oraz MemoryOS 2.0.34. Jeśli tak, hosty należy traktować jako potencjalnie skompromitowane.
- Natychmiast zablokować użycie zagrożonych wersji i przypiąć zależności do bezpiecznych wydań.
- Przeprowadzić pełną rotację wszystkich sekretów dostępnych na zainfekowanych maszynach i runnerach CI/CD.
- Unieważnić tokeny npm, PyPI, GitHub, GitLab, klucze chmurowe, klucze SSH oraz inne dane uwierzytelniające obecne w środowisku.
- Sprawdzić historię publikacji pakietów i workflow automatyzacji pod kątem nieautoryzowanych zmian.
- Wyszukać i zatrzymać procesy powiązane z
sckit. - Przeanalizować ruch sieciowy pod kątem prób eksfiltracji danych oraz zablokować podejrzaną komunikację na poziomie DNS, proxy i EDR.
W dłuższej perspektywie warto wdrożyć trwałe środki ochronne, takie jak obowiązkowe pinowanie wersji, kontrola lockfile, skanowanie zależności pod kątem ryzyk supply chain, ograniczanie uprawnień tokenów publikacyjnych, stosowanie krótkotrwałych poświadczeń oraz utwardzenie GitHub Actions.
Podsumowanie
Incydent z MemTensor pokazuje, że współczesne ataki na open source coraz częściej łączą kompromitację pipeline’ów wydawniczych, kradzież sekretów i zdolność do dalszej propagacji. Złośliwe wersje legalnych pakietów w npm i PyPI uruchamiały wieloplatformowy implant sckit, który celował w poświadczenia deweloperskie, chmurowe i publikacyjne.
Dla zespołów bezpieczeństwa kluczowe znaczenie ma szybka identyfikacja użytych wersji, pełna rotacja sekretów, analiza środowisk CI/CD oraz traktowanie każdego uruchomienia zainfekowanego pakietu jako realnego incydentu bezpieczeństwa.
Źródła
- The Hacker News — https://thehackernews.com/2026/09/compromised-memtensor-packages-deliver.html
- SafeDep — MemTensor npm and PyPI Packages Hit by a Go Worm — https://safedep.io/memtensor-sckit-worm-npm-pypi/
- StepSecurity Threat Intel — https://www.stepsecurity.io/threat-intel