CVE-2026-50014

Menadżer pakietów pnpm przed wersją 9.15.0 niewłaściwie obsługuje nadpisania i globalną pamięć podręczną. Nadpisania z jednego workspace'u przenikają do metadanych npm zapisanych w globalnej pamięci podręcznej, co może prowadzić do nieautoryzowanego wykonania kodu w innych workspace'ach.

pacquet, komponent menedżera pakietów Rust dostarczany w pakiecie npm pnpm w wersjach >=12.0.0-alpha.0 i <12.0.0-alpha.5, nie waliduje ścieżek aliasów/nazw zależności pochodzących z pliku lockfile przed użyciem ich w operacjach łączenia na poziomie systemu plików podczas instalacji. Gdy użytkownik instaluje projekt z lockfile dostarczonym przez atakującego przy użyciu --trust-lockfile lub zamrożonego lockfile, wpisy aliasów zawierające segmenty traversal ścieżki (np. '../../escaped-link') są używane podczas tworzenia linków zależności i pakietów, miejsc docelowych bin, wpisów hoisted i slotów virtual-store, co pozwala na tworzenie dowiązań symbolicznych i katalogów poza zamierzonym projektem i granicami node_modules. Wersja 12.0.0-alpha.5 waliduje nazwy zależności i każdą ścieżkę slotu virtual-store za pomocą wspólnego pomocnika safe-join containment przed materializacją systemu plików, odrzucając traversal, ścieżki bezwzględne, specyficzne dla platformy i zarezerwowane nazwy z błędem ERR_PNPM_INVALID_DEPENDENCY_NAME.

pnpm w wersjach 11.0.0 przed 11.11.0 oraz 10.7.0 przed 10.34.5 rozwija placeholdery zmiennych środowiskowych ${VAR} w ustawieniach httpProxy, httpsProxy i noProxy odczytanych z pliku pnpm-workspace.yaml projektu. Ponieważ manifest jest kontrolowany przez repozytorium, a klucze proxy zostały pominięte w zestawie kluczy docelowych żądań, które w przeciwnym razie tłumią rozwijanie placeholderów dla niezaufanych manifestów (jak już zrobiono dla registry, pnprServer, registries i namedRegistries), atakujący kontrolujący plik pnpm-workspace.yaml w repozytorium może spowodować, że ofiara, która sklonuje repozytorium i uruchomi polecenie pnpm (np. pnpm install), rozwinie sekrety środowiskowe, takie jak NPM_TOKEN lub GITHUB_TOKEN, do nazwy hosta proxy lub userinfo i skieruje ruch instalacyjny — oraz odpowiadające zapytania DNS — przez host kontrolowany przez atakującego. Eksfiltracja następuje podczas ładowania konfiguracji, przed wykonaniem jakiegokolwiek skryptu cyklu życia. Poprawione w pnpm 11.11.0 i 10.34.5.

pnpm przed wersjami 10.34.5 i 11.11.0 akceptuje ścieżkę traversal w nazwie pakietu w manifeście package.json tarballa. Podczas instalacji może to prowadzić do rozpakowania pakietu poza katalogiem node_modules i nadpisania dowolnych plików w systemie, nawet przy użyciu --ignore-scripts.

pnpm przed wersjami 10.34.5 i 11.11.0 parsuje nazwy pakietów z kluczy pnpm-lock.yaml bez walidacji, co może prowadzić do zapisu zawartości pakietów poza katalogiem node_modules podczas instalacji. Jeśli dozwolone są skrypty życia, może to umożliwić wykonanie kodu.

W menedżerze pakietów pnpm przed wersjami 10.34.4 i 11.7.0, spreparowany alias w pliku lockfile może zostać umieszczony bezpośrednio w katalogu node_modules. Aliasy typu traversal mogą opuścić ten katalog, a zastrzeżone aliasy, takie jak .bin lub .pnpm, mogą nadpisać strukturę należącą do pnpm.

pnpm przed wersjami 10.34.4 i 11.8.0 akceptuje nazwy pakietów z sekcji configDependencies pliku pnpm-lock.yaml i używa ich bezpośrednio do tworzenia dowiązań symbolicznych w katalogu node_modules/.pnpm-config. Złośliwe repozytorium może dostarczyć spreparowany plik blokady zawierający nazwę konfiguracji z sekwencją nawigacji (traversal), co prowadzi do stworzenia dowiązania poza zamierzonym katalogiem.

W pnpm przed wersjami 10.34.4 i 11.7.0, spreparowany wpis łatki mógł rozwiązywać ścieżki poza skonfigurowanym katalogiem poprawek, co pozwalało na usunięcie dowolnego dostępnego pliku za pomocą polecenia pnpm patch-remove.

Menedżer pakietów pnpm w wersjach od 11.3.0 do 11.5.3 zawiera podatność, w której polecenie `pnpm stage download` tworzyło lokalną nazwę pliku na podstawie nazwy pakietu i wersji pochodzących z rejestru. Złośliwy manifest mógł spowodować zapis pliku poza wybranym katalogiem docelowym, nadpisując inny dostępny plik.

W pnpm przed wersjami 10.34.2 i 11.5.3 odkryto podatność polegającą na tym, że klucze obiektu bin w manifeście, takie jak "", "." i "..", przechodziły przez walidację nazw binarnych. Gdy złośliwy pakiet został zainstalowany globalnie, późniejsze operacje globalnego usuwania, aktualizacji lub dodawania zamienników mogły ponownie wyprowadzić te nazwy z zainstalowanego manifestu i przekazać je do funkcji removeBin z użyciem path.join(globalBinDir, binName). Dla "." celuje to w globalny katalog binarny, a dla ".." w jego katalog nadrzędny.