Ta strona używa plików cookies, aby zapewnić najlepszą jakość korzystania z naszego serwisu oraz do celów analitycznych. Klikając "Akceptuję", wyrażasz zgodę na używanie wszystkich plików cookies. Możesz również odrzucić zgodę, co spowoduje zablokowanie plików cookies analitycznych. Więcej informacji znajdziesz w naszej Polityce Prywatności.
GitHub zaostrza publikowanie pakietów npm po luce zagrażającej ponad 1500 pakietom
Niezweryfikowane konfiguracje npm trusted publishing wygasają po 48 godzinach.
Pierwsza udana publikacja wiąże konfigurację z niezmienną tożsamością repozytorium.
Badacze znaleźli ponad 1500 potencjalnie podatnych pakietów pobranych łącznie ponad 10 milionów razy.
Zmiana ogranicza ryzyko związane z przejęciem nazwy repozytorium po jego przemianowaniu, przeniesieniu lub usunięciu.
Sponsorowane
Odkryj rewolucyjną metodę nauki języków
Sprawdź jak w 30 dni opanować podstawy dowolnego języka obcego bez wychodzenia z domu.
GitHub zaostrza zasady publikowania pakietów npm po ujawnieniu luki, która mogła pozwolić atakującemu na wypuszczenie nowej wersji cudzego pakietu bez kradzieży danych logowania jego właściciela. Firma wprowadziła wygaszanie niezweryfikowanych konfiguracji npm trusted publishing po 48 godzinach od ich utworzenia. Zmiana jest odpowiedzią na badania Bloom Security, według których problem mógł otworzyć drogę do przejęcia ponad 1500 pakietów i ataków na łańcuch dostaw oprogramowania.
GitHub skraca okno na weryfikację
Nowa konfiguracja trusted publishing musi przeprowadzić pierwszą udaną publikację w ciągu dwóch dni. Po jej zakończeniu konfiguracja zostaje zweryfikowana i przestaje podlegać automatycznemu wygasaniu. GitHub wiąże ją wtedy z niezmienną tożsamością repozytorium, a nie tylko z jego bieżącym adresem tekstowym. Jeżeli zmieni się tożsamość repozytorium lub projektu, potrzebna jest nowa relacja zaufania i zaczyna się kolejne, 48 godzinne okno walidacji. Zwykłe edycje konfiguracji nie uruchamiają tego terminu ponownie.
Problem tkwił w sposobie identyfikacji repozytorium
Trusted publishing trafiło do npm w lipcu 2025 roku jako sposób na publikowanie pakietów z platform
Słownik artykułu
Pojęcia, które warto znać
Krótkie objaśnienia terminów występujących w tekście. Każde hasło prowadzi do szerszej definicji i przykładów użycia.
, krótkotrwały token przeznaczony dla konkretnego uruchomienia. Rejestr npm porównuje go z wcześniej ustaloną konfiguracją zaufania. Takie podejście ogranicza potrzebę przechowywania, ręcznej wymiany i ochrony stałych danych uwierzytelniających. Mechanizm automatycznie tworzy także informacje o pochodzeniu pakietu, które pomagają ustalić, gdzie został zbudowany i kto go opublikował.
Bloom Security ustaliło jednak, że przed pierwszą udaną publikacją npm opierał zaufanie przede wszystkim na slugu repozytorium, czyli połączeniu nazwy właściciela lub organizacji z nazwą projektu. GitHub przekazuje w tokenach OIDC także numeryczne identyfikatory, które pozostają takie same po przemianowaniu lub przeniesieniu repozytorium, lecz npm nie uwzględniał ich w pełni przed pierwszą publikacją. W efekcie zaufanie mogło być przypisane do adresu, a nie do trwałej tożsamości projektu. Gdy taki adres stawał się ponownie dostępny, jego nowe wykorzystanie mogło zostać potraktowane jako zgodne z wcześniejszą konfiguracją.
Luka dotyczyła konfiguracji wskazującej repozytorium, z którego nie opublikowano jeszcze żadnej wersji pakietu.
Przemianowanie, przeniesienie lub usunięcie repozytorium mogło zmienić dostępność jego tekstowego adresu.
Złośliwa wersja mogła zachować nazwę legalnego pakietu, jego reputację, liczbę pobrań i relacje z projektami zależnymi.
Według badaczy scenariusz nie wymagał kradzieży danych logowania, wiedzy wewnętrznej ani wyścigu czasowego.
Skala ryzyka dla pakietów i ich użytkowników
Badacze nazwali opisany wariant ataku SlugFest. Według Bloom Security znaleziono ponad 1500 podatnych pakietów, które łącznie pobrano więcej niż 10 milionów razy. Opublikowanie złośliwej wersji pod prawidłową nazwą mogłoby wykorzystać istniejącą reputację pakietu oraz jego pozycję w zależnościach innych projektów. To istotna różnica względem ataku wymierzonego w pojedyncze konto, ponieważ skażony pakiet może być pobierany przez wiele aplikacji i środowisk budowania.
Ryzyko jest większe w środowiskach, w których zależności są aktualizowane lub wybierane automatycznie. Bloom Security zwraca uwagę, że agenci AI działający na komputerach deweloperów mogą samodzielnie rozwiązywać zależności, preferować najnowsze wersje i rzadziej wymagać ręcznego potwierdzenia źródła pakietu. W takim modelu złośliwa wersja, która zachowuje wiarygodną nazwę i dotychczasowe powiązania, może zostać pobrana bez wyraźnej decyzji człowieka. Nie oznacza to, że każdy agent AI jest podatny, ale pokazuje, jak automatyzacja może zwiększać skutki problemów w łańcuchu dostaw.
Co oznacza zmiana dla opiekunów pakietów
Najważniejsza konsekwencja zmiany polega na tym, że samo utworzenie konfiguracji nie wystarcza już do utrzymania długotrwałego zaufania. Opiekunowie pakietów korzystający z npm trusted publishing powinni zwrócić uwagę na to, czy pierwsza publikacja została pomyślnie zakończona, oraz czy później zmieniała się tożsamość wskazanego repozytorium. Znaczenie ma także sposób zarządzania nazwami projektów, ponieważ przemianowanie, transfer lub usunięcie repozytorium może wpływać na relację między kodem źródłowym a pakietem. GitHub poinformował również, że npm odrzuca teraz tokeny trusted publishing pochodzące ze zdarzeń GitHub Actions typu issue_comment, przy zachowaniu wcześniejszego ograniczenia dotyczącego pull_request_target.
Wnioski z badania dotyczą szerszej zasady bezpieczeństwa: czytelna nazwa nie powinna być jedynym dowodem tożsamości obiektu, któremu przyznano zaufanie. W systemach publikowania oprogramowania trzeba rozróżniać adres projektu, który może się zmienić, od jego trwałego identyfikatora. Wprowadzone przez GitHub wygasanie daje czas na sprawdzenie nowej konfiguracji, a pierwsza udana publikacja ma powiązać ją z niezmienną tożsamością repozytorium.
Nie jest to odosobniony problem ekosystemów deweloperskich
Bloom Security wcześniej opisywało podobny typ ryzyka w katalogach rozszerzeń Open VSX i Microsoft VS Code Marketplace. Pakiety rozszerzeń mogły odwoływać się do nieistniejących dodatków, a przejęcie wolnej przestrzeni nazw mogło sprawić, że złośliwe rozszerzenie zostałoby dołączone do zaufanego pakietu. Badacze wskazali 87 takich pakietów w Open VSX i 677 w katalogu VS Code Marketplace. Oba przypadki pokazują, że bezpieczeństwo zależności zależy nie tylko od ochrony kont i sekretów, lecz także od trwałego oraz jednoznacznego powiązania nazw, repozytoriów i publikowanych komponentów.
