CVE-2026-55700

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.

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.

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.

Menedżer pakietów pnpm przed wersjami 10.34.2 i 11.5.3 przechowuje metadane bootstrap menedżera pakietów w pierwszym dokumencie YAML pliku pnpm-lock.yaml. Złośliwe repozytorium może wykorzystać ten mechanizm, aby ominąć świeże rozwiązywanie wersji menedżera pakietów i spowodować instalację oraz wykonanie dowolnego kodu podczas automatycznej zmiany wersji.

pnpm przed wersjami 10.34.2 i 11.5.3 umożliwia instalację zależności konfiguracyjnych zdefiniowanych w pliku pnpm-workspace.yaml przed wykonaniem poleceń. Repozytorium może zadeklarować pacquet lub @pnpm/pacquet jako zależność konfiguracyjną, a pnpm traktuje tę zależność jako zgodę na użycie silnika instalacyjnego. Podczas instalacji pnpm rozwiązuje platformowo-specyficzny plik binarny @pacquet/<platform>-<arch>/pacquet z katalogu node_modules/.pnpm-config/<packageName> i uruchamia go jako programista lub użytkownik CI.

W pnpm przed wersjami 10.34.2 i 11.5.3, normalizator sufiksów peer-dependency błędnie usuwał tekst w nawiasach z lokalizatorów git, URL, tarball, plików i innych. Zatwierdzenie jednego źródła mogło autoryzować inne, kontrolowane przez atakującego źródło, którego lokalizator został znormalizowany do tej samej wartości.

Podatność w menedżerze pakietów pnpm przed wersjami 10.34.2 i 11.5.3 pozwala na rozwijanie zmiennych środowiskowych ${ENV_VAR} z plików .npmrc i pnpm-workspace.yaml kontrolowanych przez repozytorium. Złośliwe repozytorium może wysłać tajne dane środowiskowe ofiary do wybranego przez atakującego rejestru przed uruchomieniem skryptów cyklu życia.

W pnpm przed wersjami 10.34.0 i 11.4.0, polecenie `pnpm install` w trybie niezamrożonym może zaakceptować nową zdalną zawartość pakietu po wykryciu niezgodności sumy kontrolnej z plikiem pnpm-lock.yaml. Mimo że pakiet jest zablokowany z wartością integralności, a rejestr zwraca inne dane, pnpm naprawia rozpoznawanie, aktualizuje plik blokady i instaluje nową zawartość, kończąc sukcesem.