Katalog podatności CVE

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 przed 3.11.7 zawiera podatność obejścia listy dozwolonych modułów w funkcji isPathAllowedForModule, która używa dopasowania prefiksu ciągu znaków zamiast porównania z granicami ścieżki. Atakujący może uzyskać dostęp do niedozwolonych pakietów dzielących prefiks z modułami z listy dozwolonych, wykonując względne require z dozwolonych pakietów przy wyłączonym ładowaniu tranzytywnym.

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.

W wersjach vm2 ≤ 3.11.6 opcja VM({ timeout }) nie jest egzekwowana dla kodu wykonywanego poza synchronicznym wywołaniem VM#run(). Sandboxowany kod może zarejestrować wywołanie zwrotne FinalizationRegistry i po zwolnieniu obiektu zablokować pętlę zdarzeń hosta na nieograniczony czas, powodując denial of service.

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 w wersjach od 3.11.0 do 3.11.6 ujawnia bezwzględne ścieżki systemu plików hosta do kodu w sandboxie poprzez formatowanie stosu błędów. Kod dostarczony przez atakującego może wymusić na transformatorze źródła hosta zgłoszenie SyntaxError i odczytać właściwość .stack błędu, omijając redakcję ścieżek hosta po stronie sandboxa. Domyślne konfiguracje new VM() i new NodeVM() są podatne bez specjalnych opcji.

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.

vm2 w wersjach <= 3.11.7 udostępnia hostowy moduł util w sandboxie jako niefiltrowaną płytką kopię, a przestarzały wbudowany moduł sys (alias hostowego util) jest udostępniany przez ogólny loader wbudowany. W Node.js >= 22.9 daje to kodowi w sandboxie dostęp do util.getCallSites(), który zwraca pełny stos wywołań procesu hosta, w tym bezwzględne ścieżki plików, nazwy funkcji i numery linii. Podatność została naprawiona w vm2 3.11.8.

W vgmstream do wersji r2117 wykryto lukę bezpieczeństwa w funkcji parse_mus w pliku src/meta/mus_acm.c. Manipulacja prowadzi do zużycia zasobów, a atak może być przeprowadzony zdalnie. Poprawka jest identyfikowana jako ae37662ad626254ddd96ad69ac263792d7a92024.

Nieuwierzytelniona podatność na Cross-Site Scripting (XSS) w wtyczce Visitor Traffic Real Time Statistics Pro w wersji ≤ 11.21. Atakujący może wstrzyknąć złośliwe skrypty bez uwierzytelnienia.

Nieuwierzytelniona podatność na Cross-Site Scripting (XSS) w wtyczce WP Inventory Manager w wersji ≤ 2.5.4. Atakujący może wykonać skrypty w przeglądarce ofiary bez uwierzytelnienia.

Biblioteka google-protobuf zawiera nieograniczoną rekursję przy parsowaniu nieznanych pól grupowych protobuf. Atakujący może wysłać mały, spreparowany pakiet z głęboko zagnieżdżonymi bajtami START_GROUP do usługi Node.js wywołującej deserializeBinary(), co powoduje błąd RangeError: Maximum call stack size exceeded i awarię procesu.

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ść niewłaściwej neutralizacji danych wyjściowych w logach w team-alembic AshAuthentication pozwala nieuwierzytelnionemu atakującemu sfałszować wpisy logów aplikacji poprzez przesłanie tożsamości resetowania hasła zawierającej znaki nowej linii lub znaki kontrolne. Funkcja AshAuthentication.Strategy.Password.RequestPasswordReset.run/3 interpoluje argument tożsamości do szablonów Logger.warning/1 bez escapowania, obcinania lub ograniczenia typu, co pozwala atakującemu wybrać tag ważności i treść wpisów. Problem dotyczy ash_authentication od 4.2.0 przed 4.15.0 oraz od 5.0.0-rc.0 przed 5.0.0-rc.14.

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.