Katalog podatności CVE

W Vendure funkcja createCustomerAndUser w zewnętrznym uwierzytelnianiu pobiera istniejące konto po adresie e-mail i łączy z nim nową metodę uwierzytelniania bez weryfikacji właściciela e-maila. Atakujący może użyć niezweryfikowanego e-maila, aby przejąć konto ofiary.

W vm2 przed wersją 3.11.6 konfiguracja builtin: ['*'] nie ogranicza dostępu do modułów os i dns, co pozwala kodowi w piaskownicy na odczytanie informacji o procesie hosta i topologii sieci. Atakujący mogą użyć funkcji dns.setServers(), aby przejąć globalny resolver DNS procesu hosta.

Biblioteka vm2 w wersjach do 3.11.6 nieprawidłowo normalizuje specyfikatory modułów wbudowanych z prefiksem 'node:' przy dopasowywaniu negatywnych (blokujących) wpisów w polityce require NodeVM. W efekcie polityka taka jak ['*', '-node:child_process'] nie blokuje modułu child_process, ponieważ dopasowanie odbywa się przez dokładne porównanie ciągów z kanonicznymi nazwami. Kod w sandboxie może więc uzyskać dostęp do API uruchamiania procesów (execSync, spawn), co odpowiada możliwości wykonania poleceń na hoście.

W wersjach vm2 od 3.10.1 do 3.11.6 istnieje możliwość ucieczki z piaskownicy za pomocą WebAssembly.compileStreaming i instantiateStreaming. Atakujący może uzyskać dostęp do obiektu process w środowisku Node.js 26, co daje pełną kontrolę nad procesem hosta.

W wersjach vm2 przed 3.11.8 występuje luka umożliwiająca ucieczkę z piaskownicy przez obiekty console._stdout i console._stderr. Atakujący może nadpisać metodę emit w EventEmitter.prototype i wykonać kod w procesie hosta, omijając ograniczenia generowania kodu.

W wersjach vm2 od 3.11.0 do 3.11.8 nie są odpowiednio chronione prototypy TypedArray i ArrayBuffer przed modyfikacją przez kod w piaskownicy. Atakujący może zmienić prototypy, co wpływa na tablice hosta i może prowadzić do nieautoryzowanych działań.

vm2 w wersjach przed 3.11.7 zawiera błąd nieprawidłowej autoryzacji w mechanizmie sprawdzania listy dozwolonych pakietów zewnętrznych, który używa niedokładnego dopasowania podciągu zamiast pełnej walidacji granic nazwy pakietu. Atakujący mogą obejść listę dozwolonych, żądając pakietu o kolidującej nazwie zawierającej podciąg dozwolonego pakietu, co powoduje załadowanie i wykonanie nieautoryzowanych pakietów hosta w kontekście hosta.

vm2 w wersjach od 3.9.6 do 3.11.6 jest podatny na obejście listy dozwolonych wbudowanych modułów NodeVM, co umożliwia ucieczkę z sandboxa w Node.js 24 i nowszych, gdy osadzający jawnie zezwoli na wbudowany moduł node:test. W Node.js 24+ module.builtinModules ujawnia klucz node:test, który nie jest objęty ochroną DANGEROUS_BUILTINS vm2, a ponieważ requireImpl() usuwa tylko jeden prefiks 'node:', kod sandboxa wywołujący require('node:node:test') otrzymuje proxy do modułu hosta, a wywołania node:test.run() z atakującym kontrolowanym execArgv (np. --eval) wykonują dowolny kod JavaScript w nieograniczonym procesie hosta.

vm2 w wersjach przed 3.11.7 ujawnia współdzieloną pulę buforów Node (Buffer pool) kodowi w sandboxie, umożliwiając ujawnienie pamięci hosta używanej przez Buffer.from, Buffer.concat i powiązane alokacje. Kod w sandboxie może czytać i zapisywać bufory hosta, uzyskując ArrayBuffers z małych alokacji, co prowadzi do ujawnienia wrażliwych danych i potencjalnej odmowy usługi.

vm2 w wersjach przed 3.11.7 zawiera podatność na zdalne wykonanie kodu, gdy require.external jest włączone bez jawnego require.root wykluczającego node_modules. Kod w sandboxie może zażądać własnego pakietu vm2, utworzyć nieograniczoną instancję NodeVM i wykonać dowolne polecenia systemu operacyjnego hosta poprzez child_process.

vm2 w wersjach od 3.10.2 do 3.11.6 zawiera podatność na ucieczkę z sandboxa w Node.js 26, gdzie Promise.prototype.finally() omija zabezpieczenia vm2 z powodu nieaktualnego protectora PromiseThenLookupChain w V8 14.6. Atakujący mogą to wykorzystać, tworząc funkcję asynchroniczną zwracającą Promise z kontrolowanym przez atakującego konstruktorem Symbol.species, co pozwala dotrzeć do konstruktora Function hosta i obiektu process w celu wykonania dowolnego kodu.

vm2 w wersjach od 3.11.3 do 3.11.6 ujawnia moduł tls hosta kodowi w sandboxie NodeVM, umożliwiając atakującym wywołanie tls.setDefaultCACertificates() i zastąpienie certyfikatów CA w całym procesie. Atakujący z dostępem do dozwolonych wbudowanych modułów tls i url mogą użyć URLSearchParams do tworzenia tablic w domenie hosta i manipulacji magazynem zaufania TLS, co umożliwia klientom HTTPS hosta akceptowanie certyfikatów kontrolowanych przez atakującego.

vm2 w wersjach od 3.11.3 do 3.11.6 ujawnia rzeczywisty https.globalAgent procesu hosta kodowi w sandboxie, gdy NodeVM jest jawnie skonfigurowany do zezwalania na require('https'). Mimo że moduły hosta są opakowane w proxy tylko do odczytu, wywołania metod takie jak Agent.prototype.on() są przekazywane do obiektu hosta, więc kod sandboxa może zarejestrować nasłuchiwacz zdarzenia 'free' agenta. Gdy niezwiązane żądanie HTTPS hosta zwalnia połączenie z puli, nasłuchiwacz otrzymuje opcje żądania hosta i TLSSocket, co pozwala odczytać nagłówek Authorization, docelowy host/port, treści odpowiedzi oraz wysyłać uwierzytelnione żądania skradzionymi poświadczeniami.

vm2 w wersjach od 3.11.3 do 3.11.6 ujawnia moduł crypto hosta Node.js sandboxowi NodeVM, gdy wbudowany moduł crypto jest dozwolony. Mimo że moduł jest prezentowany przez rekurencyjne proxy tylko do odczytu, jego wywoływalne eksporty nadal wykonują się z uprawnieniami procesu hosta, więc kod sandboxa może wywołać crypto.setEngine() ze ścieżką do dostarczonej przez atakującego biblioteki natywnej, którą OpenSSL ładuje przez dynamiczny loader systemu, wykonując kod natywny w procesie hosta przed odrzuceniem walidacji symboli. Wykorzystanie wymaga tylko wbudowanego modułu crypto i prowadzi do ucieczki z sandboxa oraz wykonania dowolnego kodu natywnego.

vm2 w wersjach od 3.11.3 do 3.11.6 ujawnia moduł node:sqlite hosta Node.js kodowi w NodeVM, gdy ten wbudowany moduł jest dozwolony jawnie lub przez builtin: ['*']. Moduł jest opakowany w vm.readonly(), co uniemożliwia przypisywanie właściwości, ale pozostawia osiągalne funkcje o uprawnieniach hosta; dodatkowo resolver traktuje każde żądanie zaczynające się od 'node:' jako żądanie modułu rdzeniowego, a runtime usuwa tylko jeden prefiks 'node:', więc żądanie 'node:node:sqlite' rozwiązuje się do skonfigurowanego wpisu node:sqlite. Kod sandboxa może utworzyć DatabaseSync w pamięci z włączonym ładowaniem rozszerzeń i wywołać DatabaseSync.loadExtension() na bibliotece natywnej z niezaufanego pakietu, co daje wykonanie dowolnego kodu natywnego poza sandboxem z uprawnieniami procesu hosta.

vm2 3.11.6 jest podatny na ucieczkę z sandboxa prowadzącą do zdalnego wykonania kodu w procesie hosta Node.js. Poprawka dla GHSA-m283-3h24-438v jest niekompletna: brama w lib/bridge.js:1624 sprawdza tożsamość tylko bezpośredniego celu wywołania przy decyzji o przebudowie/sanityzacji odrzuconej wartości Promise hosta. Zarejestrowanie handlera odrzucenia przez Function.prototype.call lub .apply (np. p.then.call(p, undefined, cb)) sprawia, że przechwycony cel to Function.prototype.call hosta, więc sanitizer nie uruchamia się i surowy błąd hosta trafia do kodu sandboxa z nienaruszonymi właściwościami. Jeśli osadzający ujawni sandboxowi Promise z domeny hosta, która odrzuca z błędem Error zawierającym nieprymitywną właściwość odwołującą się do obiektu hosta (np. err.detail = process), niezaufany kod w sandboxie uzyskuje w pełni funkcjonalne proxy do tego obiektu hosta i może wykonywać dowolne polecenia z uprawnieniami procesu hosta.

vm2, sandbox do uruchamiania niezaufanego kodu Node.js, w wersjach 3.11.4–3.11.6 błędnie traktuje tablicę przekazaną jako opcja 'require' (np. require: []) jako prawidłową konfigurację, co omija zabezpieczenie przed zagnieżdżaniem. Atakujący może następnie zażądać modułu hosta vm2, utworzyć wewnętrzny NodeVM z wybraną listą dozwolonych wbudowanych modułów (np. child_process) i wykonać dowolne polecenia z uprawnienami procesu Node.js hosta, uciekając z sandboxa. Problem naprawiono w wersji 3.11.7.

vm2 w wersjach przed 3.11.8 zawiera niekompletną poprawkę sanityzacji Error.cause, która pozwala na ucieczkę z sandboxa, gdy obiekty AggregateError opakowane przez hosta są ponownie przetwarzane w ramach jednego przejścia obsługi wyjątku. Atakujący może wykorzystać obejście wykrywania cykli w handleException, aby uzyskać dostęp do nieoczyszczonych proxy hosta osadzonych w tablicy błędów, co umożliwia pełne zdalne wykonanie kodu i ujawnienie informacji o procesie z sandboxa.

Podatność niewystarczającego wygasania sesji w AshAuthentication i AshAuthentication Phoenix pozwala unieważnionej sesji pozostać w pełni uwierzytelnioną. Gdy zasób ma skonfigurowany session_identifier :jti i wyłączone require_token_presence_for_authentication?, wartość sesji jest przechowywana jako <jti>:<subject>, ale czytniki sesji odrzucają jti i przekazują sam subject, nie sprawdzając rekordu unieważnienia. W efekcie sesja przechwycona przed wylogowaniem nadal działa.

Podatność obejścia uwierzytelniania przez słabość podstawową w AshAuthentication pozwala niepotwierdzonemu użytkownikowi uzyskać sesję, omijając obowiązkowe potwierdzenie adresu e-mail. Funkcja check_user/2 sprawdza atrybut require_confirmed_with za pomocą is_nil(Map.get(user, value)), ale gdy atrybut nie jest załadowany zwracany jest %Ash.NotLoaded{}, a gdy polityka pola go ukrywa — %Ash.ForbiddenField{}; żadna z tych wartości nie jest nil, więc gałąź odrzucenia jest pomijana. Dodatkowo sprawdzenie nie jest wykonywane, gdy akcja jest wywoływana bezpośrednio przez warstwę API, taką jak AshGraphql lub AshJsonApi.