- An advisory, CVE-2025-61927, shows happy-dom, a Node.js headless browser, can let untrusted pages run commands. Endor Labs found the first mitigation insufficient, leading to CVE-2025-62410.
- The cause is a reliance on Node.js's vm module, which its own maintainers say is not a security mechanism.
- Endor Labs suggests keeping happy-dom in a container or virtual machine when it handles pages from outside sources.
A label is not a lock
Teams trust names. When a tool says it runs code in a "sandbox", people assume the walls hold. New research from Endor Labs on a Node.js tool called happy-dom shows how much rests on that assumption.
The lesson here is that a sandbox is a promise. Someone has to have meant it as one. In this case, the building block underneath was never meant to be a security wall.
What was found, and what Endor Labs added
Happy-dom is a headless browser. It loads web pages and runs their scripts without a screen. Developers use it for crawling and for server-side requests in Node.js.
A published advisory, CVE-2025-61927, describes how JavaScript on a page can get past happy-dom's isolation. That code can then run arbitrary commands. The issue applies when the tool renders pages from untrusted sources.
The maintainer first turned off JavaScript execution on loaded pages by default. The maintainer also advised running Node.js with a flag that blocks code built from text strings.
Endor Labs' own contribution came next. Its researchers tested that advice and found it was not enough. They told the maintainer, who then published a second advisory, CVE-2025-62410.
How the escape works
Happy-dom relies on vm. This is a module built into Node.js that runs code in a separate scope. Its documentation uses words like "virtual machine" and "sandbox".
Yet the Node.js maintainers say vm is "not a security mechanism". They warn against using it for untrusted code.
In the first proof of concept, the page's code reaches the Function constructor through the "this" object. It uses that to build a function outside the vm. From there it gets the process object and Node.js's require method. That method opens the file system and other powerful tools.
The first mitigation closes that route. A second route remains: prototype pollution.
In JavaScript, most objects inherit from one root prototype. If code changes that root, every object that inherits from it changes too.
Code inside the vm can use references on "this" to reach the root prototype of the surrounding context. Endor Labs showed that this can overwrite the global toString method and cause a denial of service. The second advisory shows the same technique can lead to arbitrary code execution.
What the second fix covers, and what it leaves
The maintainer added a second Node.js flag, "--frozen-intrinsics". It stops built-in objects from being changed. That blocks the pollution attempts.
Endor Labs still has doubts. It believes untrusted code might read global values from the surrounding scope. It also thinks code could abuse side channels, which leak information indirectly.
The researchers suggested moving to a proper sandbox. The maintainer declined because of the amount of rework involved.
The researchers also suggest a second layer of protection. Keep happy-dom in a separate container or virtual machine whenever it processes pages from outside sources. They describe this as a precaution, not a proven attack.
A pattern beyond one package
Endor Labs notes that Node.js assumes the code it runs is trustworthy. Yet teams now run untrusted code there in several ways. Examples include crawlers, user-provided plugins, smart contracts and AI-generated code.
Node.js added a warning about vm in version 10. It made the warning bold and red in version 16. Packages kept treating the module as a wall anyway.
For code that must run, Endor Labs names two options. The first is the isolated-vm package. It uses the V8 Isolate, the same building block Chrome uses. It isolates better but struggles with arbitrary open-source libraries.
The second is Secure EcmaScript, a Stage 1 proposal with an implementation from Agoric. It works well with third-party code but isolates less firmly.
Questions to put to your team
Where do we run page rendering, crawling, plugins or AI-generated code in Node.js? Does any of it depend on vm, or on a package built on it, such as happy-dom?
Is JavaScript execution switched on for pages we do not control? Do those jobs run with both Node.js flags? Do they sit inside a container or virtual machine, with no access to secrets?
Ask who made the promise of safety, and whether they meant it as security. A sandbox is only as strong as the intent behind it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Endor Labs.
