DevOps / SRE / Platform · 20.08.2026, 18:31 UTC
Critical Flaw in isolated-vm Can Lead to Sandbox Escape, RCE Threat
| Schweregrad | info |
|---|---|
| CVE | ↗ |
| Kategorie | DevOps / SRE / Platform |
| Quelle | DevOps.com ↗ |
| Veröffentlicht | 20.08.2026 UTC |
Sicherheitsmeldung mit Schweregrad noch nicht bewertet. Betroffene Kennungen: CVE-2026-22709. Technische Details im Tab „Originaltext“; empfohlene Schritte in der Checkliste.
Developers for years have been using vm2, an open-source Node.js library, to run untrusted JavaScript inside a secure and isolated sandbox environment. It uses Node.js’s built-in modules and JavaScript Proxies and lets developers whitelist particular built-in Node modules or limit what the script can access. During that time, vm2 has been the default for safely running untrusted JavaScript, which Cris Staicu, senior security researcher for Endor Labs, calls “one of the hardest problems in the Node.js ecosystem.” However, over the years, there have been some two dozen instances of code breaking out of the sandbox, including one Endor Labs documented earlier this year. The problem is that vm2 is used to build a security boundary inside a single V8 execution environment using proxies and prototype scrubbing, and untrusted code shares some of the same elements, according to Staicu. Another method, isolated-vm, uses stronger techniques, a key one being that each sandbox given its own V8 Isolate, an independent and self-contained instance of the V8 JavaScript engine with separate built-ins and no shared object graph with the host. “This is the same primitive Chrome uses to separate tabs,” Staicu wrote in a new report this week. “Guest code gets no require, no host globals, and no references to host objects unless the embedder explicitly hands them over. That is a real, OS- and VM-enforced boundary, and it is why isolated-vm is trusted to run genuinely adversarial code.” Finding a Flaw That said, Endor Labs researchers discovered a critical flaw in isolated-vm that allows code …