Krytyczna luka w vm2. Piaskownica Node.js znów zawiodła

Biblioteka vm2 dla środowiska Node.js przez lata była symbolem bezpiecznego uruchamiania niezaufanego kodu JavaScript. Narzędzie, które miało chronić systemy przed niepożądanym dostępem, znalazło się jednak w centrum uwagi specjalistów od cyberbezpieczeństwa. Ponownie, bo w latach 2022–2023 również odkryto kilka luk umożliwiających ucieczkę z piaskownicy vm2.

Nowo ujawniona podatność, oznaczona jako CVE-2026-22709, umożliwia atakującym wydostanie się z odizolowanego środowiska vm2 i wykonanie dowolnego kodu w systemie hosta. To dokładnie ten scenariusz, przed którym biblioteka miała chronić. Vm2 służy do uruchamiania kodu JavaScript w bezpiecznym kontekście, bez dostępu do systemu plików i zasobów systemowych, dlatego każdy taki błąd podważa sens jej stosowania.

Problem dotyczy mechanizmu obsługi asynchroniczności. Vm2 nie izoluje poprawnie obiektów Promise, które odpowiadają za wykonywanie operacji asynchronicznych. Choć biblioteka sprawdza część wywołań zwrotnych w swojej wewnętrznej implementacji, funkcje asynchroniczne zwracają globalny obiekt Promise. Jego metody then i catch nie przechodzą odpowiedniej walidacji, co otwiera drogę do ucieczki z piaskownicy.

Odkryta luka o krytycznym znaczeniu pokazuje, że nawet po reaktywacji projektu problem ucieczek z piaskownicy wciąż pozostaje aktualny.

Od filaru SaaS do projektu wstrzymanego

Vm2 przez lata był powszechnie wykorzystywany w usługach SaaS, kompilatorach online, chatbotach oraz projektach open source. Skala użycia jest ogromna, ponieważ biblioteka trafiła do ponad 200 tysięcy repozytoriów na GitHubie. Popularność przełożyła się jednak na intensywne zainteresowanie ze strony badaczy bezpieczeństwa, którzy regularnie odkrywali kolejne sposoby obejścia zabezpieczeń.

W 2023 roku fala krytycznych błędów doprowadziła do uznania vm2 za narzędzie niebezpieczne do wykonywania niezaufanego kodu. Projekt został w praktyce zamrożony, a społeczność zaczęła szukać alternatyw. Sytuacja zmieniła się dopiero w październiku 2025 roku, gdy opiekun biblioteki, Patrik Šimek, zdecydował się na jej reaktywację.

Powrót vm2 i szybki test rzeczywistości

Wraz z wydaniem wersji 3.10.0 twórca ogłosił naprawę wszystkich znanych wówczas luk, zachowując kompatybilność nawet z bardzo starymi wersjami Node.js. Biblioteka szybko odzyskała zainteresowanie użytkowników npm, osiągając nawet milion pobrań tygodniowo. Nowa podatność pokazuje jednak, że powrót vm2 nie oznacza końca problemów.

Po ujawnieniu CVE-2026-22709 luka została częściowo załatana w wersji 3.10.1, a następnie dodatkowo zabezpieczona w wydaniu 3.10.2. Najnowsza wersja 3.10.3 zawiera dalsze poprawki, a deweloper opublikował również demonstracyjny kod exploitów, pokazujący w praktyce, jak łatwo można ominąć zabezpieczenia starszych wydań.

Vm2 miała być bezpiecznym schronieniem dla niezaufanego kodu, a coraz częściej staje się źródłem ryzyka dla całych systemów.

Popularność silniejsza niż rozsądek

Eksperci zwracają uwagę, że skala użycia vm2 pozostaje zaskakująco duża mimo jej burzliwej historii. Niestety przywiązanie programistów do znanych narzędzi bywa silniejsze niż obawy o bezpieczeństwo. Zmiana biblioteki sandboxowej w dojrzałych projektach wymaga czasu, testów i modyfikacji architektury, dlatego wiele zespołów decyduje się pozostać przy sprawdzonym, choć problematycznym rozwiązaniu.

W tym kontekście informacje o nowych lukach w vm2 powinny być traktowane priorytetowo, zwłaszcza w systemach, które wykonują kod pochodzący od użytkowników. Historia biblioteki pokazuje, że każda kolejna podatność natychmiast staje się realnym zagrożeniem.