CVE-2026-92954 (vm2 3.10.0–3.11.7) to drugi incomplete fix z tego samego okna (GHSA-hw58-p9xv-2mjh). Odrzucone Promise zwrócone z hosta do sandboxa nie są oznaczane jako obsłużone — tylko te utworzone wewnątrz sandboxa dostają handler odrzucenia. Skutek: unhandled rejection host Promise nieoczekiwanie kończy proces Node.js. To „tylko” DoS (nie RCE jak 92937), ale znów pokazuje, że granica sandbox↔host przecieka.
3.11.8.Granicę trzeba pokryć w obie strony
Kod obronny wokół granicy sandbox↔host musi obejmować wszystkie wartości przekraczające tę granicę — w obie strony. Tu opakowano Promise tworzone wewnątrz sandboxa, ale host Promise wchodzące do sandboxa pominięto. Niekompletne pokrycie granicy = luka. To ten sam wzorzec incomplete-fix, co przy Netty OCSP (kontrola nie pokrywa przypadku brzegowego) i vm2 92937.
DoS też ma znaczenie
Ubicie procesu Node.js z sandboxa to realny DoS dla usługi, która na tym sandboxie polega (np. wykonywanie user-kodu w agencie AI). Niższa dotkliwość niż RCE, ale ta sama lekcja: granica vm2 wymaga kompletnego, nie punktowego opakowania. W parze z 92937 wzmacnia wniosek: dla ścieżek z niezaufanym kodem rozważ wyjście z vm2.
Co powinien zrobić VE
Upgrade do 3.11.8 (i zaadresuj 92937 — RCE). Zinwentaryzuj miejsca, gdzie vm2 przetwarza niezaufany kod i jak krytyczna jest dostępność tej usługi. Verification: test, że odrzucone host Promise w sandboxie nie ubija procesu po upgrade.
Powiązane na blogu
- vm2 CVE-2026-92937 — RCE z tego samego okna
- Netty OCSP: fail-open — kontrola nie pokrywa przypadku brzegowego
Źródła
- CVE-2026-92954 (vm2, incomplete fix, DoS) — radar.offseq.com
- OSV — CVE-2026-92954 (fix 3.11.8) — osv.dev
Nota redakcyjna: stan informacji 28 września 2026, na podstawie publicznych źródeł. CVE-2026-92954 (vm2 3.10.0–3.11.7, DoS przez unhandled host Promise; incomplete fix GHSA-hw58-p9xv-2mjh); fix 3.11.8. W parze z CVE-2026-92937 (RCE).