Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Biblioteka vm2 od lat jest wykorzystywana w ekosystemie Node.js jako mechanizm uruchamiania nieufnego kodu JavaScript w odseparowanym środowisku. Jej celem jest ograniczenie dostępu takiego kodu do zasobów hosta, w tym procesu systemowego, plików oraz wewnętrznych interfejsów Node.js. Najnowsza krytyczna podatność pokazuje jednak, że taka izolacja może zostać przełamana, a skutkiem może być pełne wykonanie dowolnego kodu na systemie gospodarza.
W skrócie
Podatność oznaczona jako CVE-2026-26956 dotyczy biblioteki vm2 i prowadzi do tzw. sandbox escape, czyli ucieczki z izolowanego środowiska. Problem potwierdzono dla wersji 3.10.4, a publicznie udostępniono także kod PoC pokazujący sposób wykorzystania błędu. Według opublikowanych informacji luka występuje w środowiskach korzystających z Node.js 25, gdy aktywne są mechanizmy WebAssembly exception handling oraz JSTag support. Zalecanym działaniem ograniczającym ryzyko jest aktualizacja do wersji 3.10.5 lub nowszej.
Kontekst / historia
vm2 znajduje zastosowanie wszędzie tam, gdzie aplikacja musi uruchamiać kod dostarczony przez użytkownika, partnera lub zewnętrzny moduł. Dotyczy to między innymi platform edukacyjnych, narzędzi automatyzacji, usług SaaS, silników workflow oraz systemów rozszerzanych przez skrypty.
To nie pierwszy przypadek, gdy bezpieczeństwo vm2 budzi poważne zastrzeżenia. W poprzednich latach projekt wielokrotnie pojawiał się w analizach dotyczących możliwości obejścia sandboxa i uzyskania dostępu do hosta. Obecny incydent po raz kolejny pokazuje, jak trudne jest zbudowanie silnej izolacji wyłącznie na poziomie mechanizmów JavaScript, szczególnie gdy w grę wchodzą złożone funkcje silnika V8 i zachowanie samego środowiska uruchomieniowego Node.js.
Analiza techniczna
Istota podatności sprowadza się do niewłaściwej obsługi wyjątków przekraczających granicę pomiędzy sandboxem a hostem. vm2 stosuje warstwę zabezpieczeń realizowaną w JavaScript, obejmującą między innymi osłony dla wyjątków po stronie hosta oraz mechanizmy proxy opakowujące obiekty przekazywane między kontekstami.
W opisywanym scenariuszu zabezpieczenia te mogą zostać pominięte przez obsługę wyjątków WebAssembly, działającą na niższym poziomie w silniku V8. W praktyce oznacza to, że odpowiednio przygotowany błąd nie przechodzi przez standardowy mechanizm sanityzacji stosowany przez vm2.
Atak wykorzystuje specjalnie przygotowany wyjątek typu TypeError związany z konwersją obiektu Symbol do łańcucha znaków. W rezultacie do środowiska sandboxa może przedostać się obiekt błędu pochodzący bezpośrednio z kontekstu hosta. Taki obiekt nie jest już neutralnym elementem izolowanego środowiska, lecz referencją do komponentu utworzonego po stronie nadrzędnej.
To właśnie przełamanie tej granicy ma kluczowe znaczenie dla powodzenia ataku. Po uzyskaniu dostępu do obiektu utworzonego po stronie hosta napastnik może wykorzystać jego łańcuch konstruktorów do odzyskania dostępu do wewnętrznych obiektów Node.js, w tym do mechanizmów umożliwiających interakcję z procesem. Kolejnym krokiem może być już wykonanie dowolnych poleceń systemowych i pełne przejęcie kontekstu hosta.
Z punktu widzenia praktycznego luka jest szczególnie groźna tam, gdzie vm2 służy do wykonywania kodu dostarczanego przez użytkownika za pośrednictwem interfejsu webowego, API lub systemów automatyzacji. W takich środowiskach podatność może zamienić pozornie kontrolowaną funkcję uruchamiania skryptów w bezpośredni wektor zdalnego wykonania kodu.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem podatności jest całkowite naruszenie granicy zaufania między nieufnym kodem a systemem gospodarza. Organizacja, która traktuje vm2 jako podstawową barierę bezpieczeństwa, może w praktyce utracić kontrolę nad środowiskiem wykonawczym.
- zdalne wykonanie kodu na serwerze,
- dostęp do zmiennych środowiskowych i sekretów aplikacyjnych,
- odczyt lub modyfikacja plików na hoście,
- możliwość dalszego ruchu bocznego w infrastrukturze,
- przejęcie kontenerów lub usług współdzielących host,
- zakłócenie dostępności usług oraz wdrożenie trwałych mechanizmów utrzymania dostępu.
Szczególnie narażone są organizacje oferujące funkcje uruchamiania skryptów klientów, dynamiczne przetwarzanie kodu oraz środowiska wielodostępowe. W takich przypadkach kompromitacja jednej funkcji aplikacyjnej może przełożyć się na ryzyko dla całej platformy.
Rekomendacje
Podstawowym działaniem powinno być szybkie zidentyfikowanie wszystkich komponentów korzystających z vm2, zarówno bezpośrednio, jak i przez zależności pośrednie. Następnie należy przeprowadzić aktualizację do wersji 3.10.5 lub nowszej oraz zweryfikować, czy środowisko spełnia warunki sprzyjające wykorzystaniu podatności.
- przeprowadzić pełną inwentaryzację zależności Node.js w środowiskach produkcyjnych i deweloperskich,
- sprawdzić, czy wykorzystywane są Node.js 25, WebAssembly exception handling oraz JSTag support,
- ograniczyć lub czasowo wyłączyć funkcje uruchamiające nieufny kod do czasu pełnego załatania środowiska,
- uruchamiać komponenty wykonujące kod użytkownika w osobnych kontenerach lub mikroVM z minimalnymi uprawnieniami,
- nie traktować sandboxa JavaScript jako jedynej warstwy ochrony,
- monitorować procesy potomne, nietypowe polecenia systemowe i anomalie wykonania,
- przeanalizować logi pod kątem prób nadużycia funkcji skryptowych i nietypowych wyjątków,
- wdrożyć procedury szybkiego reagowania na luki w bibliotekach open source o wysokim znaczeniu operacyjnym.
Z perspektywy architektury bezpieczeństwa wniosek jest jednoznaczny: biblioteki takie jak vm2 mogą pełnić rolę dodatkowej warstwy ograniczeń, ale nie powinny być jedynym mechanizmem separacji dla kodu pochodzącego od użytkowników lub podmiotów zewnętrznych.
Podsumowanie
CVE-2026-26956 to kolejna bardzo poważna luka w vm2, która umożliwia przełamanie izolacji sandboxa i wykonanie dowolnego kodu na hoście. Mechanizm ataku wykorzystuje niewłaściwą obsługę wyjątków przekraczających granicę między sandboxem a hostem, z udziałem funkcji WebAssembly na poziomie silnika V8. Dla organizacji korzystających z vm2 w scenariuszach wykonywania nieufnego kodu oznacza to wysokie ryzyko przejęcia środowiska, dlatego priorytetem powinny być aktualizacja, ocena ekspozycji oraz wdrożenie dodatkowych warstw izolacji.
Źródła
- Critical vm2 sandbox bug lets attackers execute code on hosts — https://www.bleepingcomputer.com/news/security/critical-vm2-sandbox-bug-lets-attackers-execute-code-on-hosts/
- Sandbox Escape advisory for vm2 — https://github.com/patriksimek/vm2/security/advisories/GHSA-g644-9gfx-q4q4