Strona główna / Blog / vm2: patch lineage

Blog · analiza

vm2 CVE-2026-92945, 92951 i 92953: kiedy poprawka sandboxa nie kończy historii

Seria podatności vm2 z września to materiał o patch lineage. Dwa błędy w allowliście modułów (CVE-2026-92945 i CVE-2026-92951) zostały naprawione w 3.11.7. Ale CVE-2026-92953 — brak ochrony prototypów TypedArray i ArrayBuffer hosta — dotyczy wersji 3.11.0–3.11.7 i jest naprawiony dopiero w 3.11.8. Zespół, który zamknął findingi na 3.11.7, nadal ma podatny sandbox.

CVE-2026-92945 (GHSA-7q3f-wx44-378m, CVSS v4 2.3, fix 3.11.7): isPathAllowedForModule porównuje ścieżki jako surowe prefiksy → relatywne require z dozwolonego pakietu sięga pakietu o podobnej nazwie (przy wyłączonym ładowaniu przechodnim).
CVE-2026-92951 (GHSA-c48m-32m9-vx93, CVSS 9.9, fix 3.11.7): niezakotwiczony regex nazwy pakietu w require.external + custom require.resolve → kolidujący pakiet ładuje się z prawami hosta.
CVE-2026-92953 (GHSA-3vgf-8m4q-q4qr, CVSS v4 9.3, podatne 3.11.0–3.11.7, fix 3.11.8): kod w sandboxie modyfikuje prototypy Uint8Array, %TypedArray% i ArrayBuffer hosta; tablice tworzone później przez host dziedziczą właściwości atakującego.

Dwa podobne błędy, różne oceny

92945 i 92951 wyglądają na ten sam problem — „nazwa podobna do dozwolonej przechodzi” — ale to osobne rekordy w różnych miejscach kodu. 92945 dotyczy porównania ścieżek i ma ocenę Low (2.3), bo wymaga specyficznego układu pakietów. 92951 dotyczy listy external z własnym resolverem i ma 9.9. To dobry przykład, że dwa CVE o podobnym opisie mogą mieć zupełnie różny realny priorytet — zależnie od konfiguracji sandboxa.

Dlaczego „patched” nie znaczy „bezpieczny”

Zespół VM może zobaczyć „3.11.7 = fixed” dla 92945, 92951 i 92937 i zamknąć findingi. Tymczasem założenie bezpieczeństwa — izolacja niezaufanego kodu — jest nadal naruszane inną ścieżką (92953), a także przez 92954, również naprawiony dopiero w 3.11.8. Przy bibliotekach sandboxowych jednostką remediacji jest rodzina poprawek, a docelową wersją — najnowsza, która zamyka wszystkie znane obejścia.

Co powinien zrobić VE

Ustaw docelową wersję na 3.11.8 (nie 3.11.7) i ponownie otwórz findingi zamknięte na 3.11.7. Sprawdź faktycznie wdrożoną wersję w lockfile i obrazie kontenera. Uruchom test odpowiadający sposobowi użycia sandboxa (moduły, resolver, operacje na tablicach typowanych). Długoterminowo oceń, czy dla ścieżek z niezaufanym kodem vm2 jest właściwym narzędziem — kolejne obejścia pojawiają się regularnie.

Powiązane na blogu

Źródła

  • OSV — CVE-2026-92945 / GHSA-7q3f-wx44-378m — osv.dev
  • vm2 — GHSA-c48m-32m9-vx93 (CVE-2026-92951) — github.com
  • OSV — CVE-2026-92953 / GHSA-3vgf-8m4q-q4qr — osv.dev

Nota redakcyjna: stan informacji 6 października 2026, na podstawie draftu VMRT i publicznych advisory (OSV, GHSA). CVE-2026-92945 i CVE-2026-92951 naprawione w 3.11.7; CVE-2026-92953 (3.11.0–3.11.7) naprawione w 3.11.8. Artykuł nie potwierdza aktywnej eksploatacji.

Zapamiętaj jedno

Nie traktuj pojedynczego CVE jak niezależnej wyspy. Przy bibliotekach sandboxowych śledź rodzinę poprawek: vm2 3.11.7 zamyka trzy znane obejścia, ale 3.11.8 jest pierwszą wersją, która zamyka wszystkie z września.