--- title: "GitHub zaostrza publikowanie pakietów npm po luce zagrażającej ponad 1500 pakietom" description: "GitHub skraca ważność niezweryfikowanych konfiguracji npm trusted publishing do 48 godzin po wykryciu luki w powiązaniu repozytoriów z pakietami. Problem mógł umożliwić publikowanie złośliwych wersji ponad 1500 pakietów i doprowadzić do ataków na łańcuch dostaw oprogramowania." publisher: "Najnowsze Informacje" language: "pl-PL" canonical_url: "https://najnowsze-informacje.pl/cyberbezpieczenstwo/github-zaostrza-publikowanie-pakietow-npm-po-luce-zagrazajacej-ponad-1500-pakietom" markdown_url: "https://najnowsze-informacje.pl/cyberbezpieczenstwo/github-zaostrza-publikowanie-pakietow-npm-po-luce-zagrazajacej-ponad-1500-pakietom/index.md" date_published: "2026-10-17T21:49:53.629Z" date_modified: "2026-10-17T21:59:38.597Z" author: "Redakcja" category: "Cyberbezpieczeństwo" tags: - "npm" - "github" - "cyberbezpieczeństwo" - "łańcuch dostaw oprogramowania" - "trusted publishing" source_url: "https://thehackernews.com/2026/10/github-tightens-npm-publishing-after.html" source_name: "The Hacker News" image_url: "https://najnowsze-informacje.pl/api/media/file/cyberbezpieczenstwo-unsplash-1791914479923.jpeg" image_alt: "a group of cubes that are on a black surface" image_credit: "© Shubham Dhage / Unsplash" image_credit_url: "https://unsplash.com/@theshubhamdhage" --- # GitHub zaostrza publikowanie pakietów npm po luce zagrażającej ponad 1500 pakietom > GitHub zmienia zasady trusted publishing w npm po wykryciu luki, która mogła umożliwić przejęcie ponad 1500 pakietów bez kradzieży danych logowania. ## Kluczowe informacje - 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. 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 CI/CD, takich jak GitHub Actions, bez przechowywania długoterminowych sekretów. Dostawca procesu budowania wystawia za pośrednictwem OpenID Connect, czyli OIDC, 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. ## Wyjaśnienie pojęć ### [Trusted publishing](https://najnowsze-informacje.pl/definicje/trusted-publishing) Mechanizm publikowania pakietów npm bez przechowywania długoterminowego sekretu. Weryfikuje, czy publikacja pochodzi z wcześniej zaufanego repozytorium i procesu CI/CD. ### [CI/CD](https://najnowsze-informacje.pl/definicje/cicd) Zbiorcze określenie praktyk automatyzujących budowanie, testowanie i dostarczanie oprogramowania. CI oznacza ciągłą integrację zmian, a CD ich ciągłe dostarczanie lub wdrażanie. ### [OpenID Connect (OIDC)](https://najnowsze-informacje.pl/definicje/openid-connect-oidc) Standard używany do przekazywania informacji o tożsamości między usługami. W tym przypadku dostawca CI/CD wystawia token sprawdzany przez rejestr npm. ## Źródło pierwotne [The Hacker News](https://thehackernews.com/2026/10/github-tightens-npm-publishing-after.html) --- ## Informacje do cytowania - **Autor:** Redakcja - **Data publikacji:** 2026-10-17T21:49:53.629Z - **Ostatnia aktualizacja:** 2026-10-17T21:59:38.597Z - **Kategoria:** Cyberbezpieczeństwo - **Adres kanoniczny:** [https://najnowsze-informacje.pl/cyberbezpieczenstwo/github-zaostrza-publikowanie-pakietow-npm-po-luce-zagrazajacej-ponad-1500-pakietom](https://najnowsze-informacje.pl/cyberbezpieczenstwo/github-zaostrza-publikowanie-pakietow-npm-po-luce-zagrazajacej-ponad-1500-pakietom) - **Wersja Markdown:** [https://najnowsze-informacje.pl/cyberbezpieczenstwo/github-zaostrza-publikowanie-pakietow-npm-po-luce-zagrazajacej-ponad-1500-pakietom/index.md](https://najnowsze-informacje.pl/cyberbezpieczenstwo/github-zaostrza-publikowanie-pakietow-npm-po-luce-zagrazajacej-ponad-1500-pakietom/index.md) **Sugerowane cytowanie:** > Najnowsze Informacje, „GitHub zaostrza publikowanie pakietów npm po luce zagrażającej ponad 1500 pakietom”, 2026-10-17, https://najnowsze-informacje.pl/cyberbezpieczenstwo/github-zaostrza-publikowanie-pakietow-npm-po-luce-zagrazajacej-ponad-1500-pakietom