Katalog podatności CVE

SGLang do wersji 0.5.19 w trybie rozdzielenia prefill/decode zawiera nieuwierzytelniony endpoint PUT /route w usłudze prefill bootstrap, który pozwala atakującym zatruć tablicę routingu transferu KV. Atakujący mogą podać dowolne wartości rank_ip i rank_port, aby przekierować workery decode do kontrolowanych przez siebie endpointów. Może to powodować odmowę usługi lub ujawnienie metadanych transferu KV, w tym identyfikatorów sesji i parametrów topologii tensor-parallel.

InternLM LMDeploy do wersji 0.17.0 zawiera podatność z osiągalnym asercją w pętli migracji decode DistServe, która pozwala nieuwierzytelnionym atakującym zatrzymać silnik wnioskowania. Atakujący może przesłać migration_request z pustą listą remote_block_ids, aby wywołać AssertionError, który zawiesza pętlę silnika i powoduje niepowodzenie kolejnych żądań wnioskowania.

HUBzero CMS do wersji 2.2.32 zawiera podatność typu path traversal w procedurach obsługi przesyłania plików projektowych, która pozwala uwierzytelnionym członkom projektu zapisywać dowolne pliki poza repozytorium projektu. Atakujący mogą podać sekwencje przejścia w parametrach przesyłania, aby zapisać pliki w wybranych przez siebie ścieżkach z uprawnieniami serwera WWW, co potencjalnie umożliwia wykonanie kodu.

W vm2 w wersjach przed 3.11.2 nieprawidłowo ograniczono dostęp do globalnej zmiennej VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL. Atakujący może uzyskać dostęp do tego wewnętrznego obiektu stanu poprzez globalThis i pozyskać wrażliwe elementy wewnętrzne piaskownicy.

vm2, sandbox do uruchamiania niezaufanego kodu JavaScript, w wersjach do 3.11.3 włącznie używa przypisania indeksu z przechodzeniem po prototypie w defaultSandboxPrepareStackTrace, co pozwala kodowi w sandboxie przechwycić linie stosu błędów. Luka ma niski wpływ (kanał boczny informacji) i została naprawiona w wersji 3.11.4.

vm2 przed wersją 3.11.6 nie egzekwuje limitu bufferAllocLimit dla konstruktorów ArrayBuffer, SharedArrayBuffer i TypedArray, co pozwala atakującym alokować dowolną pamięć hosta. Atakujący mogą obejść limit alokacji bufora, używając tych wbudowanych funkcji V8 do wyczerpania pamięci procesu hosta i wywołania warunków braku pamięci.

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.

vm2 przed wersją 3.11.8 nie egzekwuje w pełni opcji allowAsync: false w VM i NodeVM. Mimo że localPromise.prototype.then jest zastąpione procedurą rzucającą błąd 'Async not available', statyczne metody Promise w sandboxie (Promise.resolve, Promise.all, Promise.race, Promise.any, Promise.allSettled) nadal asymilują dostarczone przez atakującego thenable, co pozwala na zaplanowanie pracy po zakończeniu VM.run() lub NodeVM.run() i poza skonfigurowanym limitem czasu.

vm2 do wersji 3.11.6 zawiera obejście listy zablokowanych modułów wbudowanych w NodeVM. Gdy osadzający używa symbolu wieloznacznego builtin wraz z wpisami negatywnymi (np. require: { builtin: ['*', '-fs', '-child_process'] }), wpisy negatywne są dopasowywane po dokładnej nazwie modułu, więc -fs usuwa tylko moduł fs, a nie jego podścieżki, takie jak fs/promises. Kod w sandboxie może wywołać require('fs/promises') lub require('node:fs/promises') i uzyskać dostęp do API systemu plików opartego na obietnicach.

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.

vm2 w wersjach od 3.10.0 do 3.11.7 nie oznacza jako obsłużonych obietnic zwracanych z realm hosta do sandboxa na granicy mostu. Tylko obietnice utworzone wewnątrz sandboxa są opakowywane w procedurę pochłaniającą odrzucenie, a most instaluje sanitizery odrzuceń po stronie hosta tylko wtedy, gdy kod sandboxa wywoła .then/.catch/.finally. W rezultacie kod w sandboxie może wywołać funkcję hosta zwracającą odrzuconą obietnicę i zignorować wartość zwracaną, pozostawiając obietnicę hosta nieobsłużoną, co powoduje zakończenie procesu hosta przez domyślne zachowanie Node.js.

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ń.

W vm2 w wersjach od 3.11.4 do 3.11.6 niekompletnie filtrowano zarejestrowane wewnętrzne symbole Node.js na granicy piaskownicy. Filtry w lib/setup-sandbox.js oraz sprawdzenia symboli i pułapki zapisu w lib/bridge.js używają stałej listy znanych niebezpiecznych symboli, pomijając nodejs.stream.disturbed i nodejs.stream.errored, które są eksponowane na prototypach WebStream w nowszych wersjach Node.js. Gdy osadzający udostępnia obiekt WebStream i moduł stream/web piaskownicy, kod piaskownicy może uzyskać prawdziwe symbole hosta i użyć ich jako kluczy zapisu na obiektach strumieni hosta, uszkadzając widoczny dla hosta stan strumienia. Może to obejść logikę hosta opartą na publicznych pomocnikach stanu strumienia Node.js. Nie jest to prymityw wykonania kodu hosta w zgłoszonym dowodzie podatności. To niekompletna poprawka wcześniejszego problemu filtrowania symboli nodejs.*. Naprawiono w vm2 3.11.7.

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.

Podatność w narzędziu CLI vm2 (przed wersją 3.11.7) umożliwia ucieczkę z piaskownicy i wykonanie dowolnego kodu w procesie Node.js hosta. Atakujący może dostarczyć złośliwy plik skryptu, który używa require(__filename) do ponownego wykonania siebie w środowisku hosta, omijając izolację piaskownicy i uzyskując dostęp do modułów takich jak fs i child_process.

W vm2 w wersjach od 3.9.6 przed 3.11.7 nieprawidłowo ograniczono dostęp do właściwości akcesorów na zamrożonych obiektach, co pozwala skryptom w piaskownicy obejść zabezpieczenia vm.freeze() i vm.readonly(). Atakujący może użyć Object.getOwnPropertyDescriptor() lub __lookupSetter__() do wyodrębnienia i wywołania setterów obiektów hosta bezpośrednio, modyfikując właściwości oznaczone przez osadzającego jako tylko do odczytu.

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.