Krytyczne luki w vm2 dla Node.js umożliwiają ucieczkę z sandboxa i zdalne wykonanie kodu

Wprowadzenie do problemu / definicja

Biblioteka vm2 jest jednym z najczęściej wykorzystywanych mechanizmów izolacji w ekosystemie Node.js do uruchamiania niezaufanego kodu JavaScript w odseparowanym środowisku. Jej zadaniem jest ograniczenie dostępu wykonywanego kodu do zasobów hosta, wbudowanych modułów oraz obiektów o podwyższonych uprawnieniach. Najnowsze ujawnienia pokazują jednak, że model ten pozostaje podatny na obejścia, a błędy implementacyjne mogą prowadzić do pełnej kompromitacji środowiska uruchomieniowego.

W skrócie

• W maju 2026 roku ujawniono serię krytycznych podatności w bibliotece vm2.
• Luki umożliwiają ucieczkę z sandboxa, obejście zabezpieczeń oraz wykonanie dowolnego kodu na hoście.
• Część problemów otrzymała bardzo wysokie oceny CVSS, sięgające poziomu krytycznego.
• Podatności dotyczą wielu wersji z linii 3.x, a dostawcy zaleceń wskazują na konieczność szybkiej aktualizacji.

Kontekst / historia

vm2 od lat znajduje zastosowanie w systemach, które muszą wykonywać kod dostarczony przez użytkownika, klienta lub zewnętrzny komponent. Dotyczy to między innymi platform SaaS, środowisk edukacyjnych, narzędzi CI/CD, produktów low-code i no-code oraz rozwiązań umożliwiających uruchamianie wtyczek, skryptów lub logiki wielodzierżawowej.

Nie jest to pierwszy przypadek, gdy bezpieczeństwo vm2 zostaje podważone. W przeszłości badacze wielokrotnie wykazywali, że utrzymanie szczelnej izolacji w dynamicznym środowisku JavaScript i Node.js jest wyjątkowo trudne. Każda kolejna fala poprawek usuwała wybrane klasy błędów, ale jednocześnie pojawiały się nowe ścieżki eskalacji i techniki omijania wcześniejszych zabezpieczeń.

Obecna sytuacja ma znaczenie szersze niż tylko pojedyncza biblioteka. Podważa ona założenie, że uruchamianie niezaufanego kodu w ramach jednego procesu aplikacyjnego może być wystarczająco bezpieczne bez dodatkowych warstw izolacji systemowej.

Analiza techniczna

Ujawnione podatności obejmują różne mechanizmy wewnętrzne JavaScript i Node.js. Wśród opisywanych wektorów znalazły się nadużycia związane z getterami, obsługą Promise, mechanizmami inspekcji obiektów, wyjątkami, konwersją typów, prototypami oraz metodami odpowiedzialnymi za dostęp do wewnętrznej struktury obiektów. W praktyce wszystkie te błędy prowadzą do tego samego efektu: naruszenia granicy między kontekstem izolowanym a kontekstem hosta.

vm2 opiera ochronę na przechwytywaniu i proxyfikacji obiektów JavaScript, aby kod wykonywany w sandboxie nie uzyskał bezpośredniego dostępu do uprzywilejowanych elementów środowiska. Jeśli jednak atakujący znajdzie sposób na pozyskanie referencji do obiektu hosta, uruchomienie nieprzewidzianej ścieżki silnika lub obejście walidacji wyjątków i prototypów, izolacja przestaje działać zgodnie z założeniami.

Szczególnie groźne są scenariusze, w których możliwe staje się obejście listy dozwolonych modułów w NodeVM. Jeżeli napastnik zyska możliwość załadowania modułów odpowiedzialnych za uruchamianie procesów lub interakcję z systemem operacyjnym, droga do wykonania poleceń na serwerze staje się bezpośrednia. To przekształca teoretycznie odizolowane wykonanie kodu użytkownika w pełne zdalne wykonanie kodu na hoście.

• Sandbox escape prowadzący do arbitralnego wykonania kodu.
• Bypass wcześniejszych poprawek bezpieczeństwa.
• Code injection umożliwiający przejęcie obiektów hosta.
• Obejście allowlisty modułów w NodeVM.
• Prototype pollution z możliwością dalszej eskalacji.
• Improper access control skutkujący wykonaniem poleceń systemowych.

Fakt, że poprawki publikowano etapami dla kolejnych wersji, pokazuje, iż problem nie ogranicza się do jednej luki. Mamy raczej do czynienia z serią powiązanych słabości architektonicznych i implementacyjnych, które wpływają na zaufanie do całego modelu izolacji opartego wyłącznie na vm2.

Konsekwencje / ryzyko

Dla organizacji wykorzystujących vm2 wpływ tych podatności może być krytyczny. W systemach, które umożliwiają klientom lub użytkownikom końcowym uruchamianie własnego kodu, skuteczny exploit może doprowadzić do przejęcia serwera aplikacyjnego, wycieku danych, naruszenia separacji tenantów oraz przejęcia sekretów środowiskowych.

Ryzyko nie kończy się na pojedynczej aplikacji. Jeżeli proces wykonujący sandbox ma dostęp do sieci wewnętrznej, usług chmurowych, baz danych, brokerów komunikatów lub magazynów sekretów, atakujący może wykorzystać uzyskany przyczółek do dalszego przemieszczania się po infrastrukturze.

• Zdalne wykonanie kodu na hoście.
• Ucieczka z izolacji i naruszenie separacji klientów.
• Odczyt tokenów, kluczy API i zmiennych środowiskowych.
• Uruchamianie poleceń systemowych i pobieranie kolejnych ładunków.
• Pivoting do innych systemów w tej samej sieci.
• Zakłócenie działania usług lub sabotaż operacyjny.

Rekomendacje

Organizacje korzystające z vm2 powinny potraktować sprawę jako priorytet i wdrożyć działania zarówno natychmiastowe, jak i długoterminowe.

• Przeprowadzić pełną inwentaryzację użycia vm2, w tym zależności pośrednich w projektach Node.js.
• Zaktualizować bibliotekę do najnowszej poprawionej wersji oraz zweryfikować kompatybilność aplikacji po wdrożeniu poprawek.
• Przyjąć założenie, że sam sandbox może zostać obejściy, i nie traktować go jako jedynej warstwy ochrony.
• Uruchamiać niezaufany kod w dodatkowo izolowanych granicach bezpieczeństwa, takich jak kontenery, maszyny wirtualne, microVM lub odseparowane węzły wykonawcze.
• Ograniczyć uprawnienia procesu, dostęp do sieci, sekretów i zasobów hosta zgodnie z zasadą najmniejszych uprawnień.
• Rozszerzyć monitoring o wykrywanie nietypowych uruchomień procesów, anomalii w obsłudze wyjątków, prób ładowania modułów systemowych oraz nieautoryzowanych połączeń wychodzących.
• Zweryfikować model bezpieczeństwa produktu wszędzie tam, gdzie biznes zależy od wykonywania kodu dostarczanego przez użytkownika.

Podsumowanie

Seria krytycznych luk w vm2 potwierdza, że bezpieczne wykonywanie niezaufanego kodu JavaScript pozostaje jednym z najtrudniejszych problemów inżynieryjnych w nowoczesnych aplikacjach. W tym przypadku zagrożenie nie sprowadza się do pojedynczego błędu, lecz do wielu mechanizmów umożliwiających ucieczkę z sandboxa i eskalację uprawnień.

Dla zespołów bezpieczeństwa, administratorów i twórców platform uruchamiających kod klientów oznacza to konieczność szybkiej aktualizacji, ponownej oceny ekspozycji oraz wdrożenia dodatkowych warstw ochrony poza samą biblioteką. vm2 może być elementem architektury bezpieczeństwa, ale nie powinien być traktowany jako samowystarczalne zabezpieczenie przed uruchamianiem niezaufanego kodu.

Źródła

• The Hacker News – vm2 Node.js Library Vulnerabilities Enable Sandbox Escape and Arbitrary Code Execution — https://thehackernews.com/2026/05/vm2-nodejs-library-vulnerabilities.html
• GitHub Advisory Database – CVE-2026-24118 — https://github.com/advisories
• GitHub Advisory Database – CVE-2026-43999 — https://github.com/advisories
• GitHub Advisory Database – CVE-2026-44008 — https://github.com/advisories
• npm – vm2 package information — https://www.npmjs.com/package/vm2