GHSA-98XX-8MX4-X7CM
Vulnerability from github – Published: 2026-10-01 15:27 – Updated: 2026-10-01 15:27Summary
vm2 3.11.6 exposes the host tls module to a NodeVM when that builtin is explicitly allowed. Although the module object is wrapped as read-only, its functions still execute against process-wide host state. On Node.js versions that provide tls.setDefaultCACertificates(), sandbox code can replace the certificate authorities trusted by subsequent host-realm TLS clients.
The exploit needs only the narrowly allowed tls and url builtins. It does not require fs, process, module, child_process, an external package, or a general '*' builtin grant. A host HTTPS request rejected an attacker certificate before sandbox execution, then accepted the same certificate and returned an application marker after the sandbox replaced the default CA list.
This crosses the intended sandbox boundary. An attacker can make host HTTPS clients trust an attacker-controlled CA, enabling credential theft and response tampering when the attacker can influence a subsequent destination or network path. Replacing the list also removes the normal trust roots, disrupting unrelated host TLS traffic.
Details
The vulnerable boundary is the default builtin loader in lib/builtin.js. Builtins that are not classified as dangerous are exposed through a recursive read-only bridge:
builtins.set(key, special ? special : vm => vm.readonly(hostRequire(key)));
The read-only wrapper prevents ordinary property assignment through the sandbox proxy. It does not make calls such as tls.setDefaultCACertificates() sandbox-local. That function changes the default CA list for the current Node.js thread and affects subsequent TLS connections that do not provide their own ca option.
The dangerous-builtin list now rejects dns because dns.setServers() mutates process-wide host networking state. It does not reject tls, even though current Node.js exposes an equivalent process-wide trust mutation through it.
A direct call with a normal sandbox array is not necessary. The native TLS function requires an actual host-realm array. The allowed host url module provides one:
const tls = require('tls');
const {URLSearchParams} = require('url');
const hostArray = new URLSearchParams(
'ca=' + encodeURIComponent(attackerCaPem)
).getAll('ca');
tls.setDefaultCACertificates(hostArray);
URLSearchParams.getAll() executes in the host realm and returns a host array containing the attacker-controlled PEM string. vm2 maps that array into the sandbox. When the mapped value is passed back to the TLS function, the bridge unwraps it to the original host array, satisfying the native type check. The TLS function then replaces the host thread's default CA set.
The complete exploit flow is:
attacker-controlled NodeVM program
-> require only the allowed tls and url builtins
-> URLSearchParams.getAll() creates a host array containing attacker CA PEM
-> bridge unwraps the mapped array when passed back to tls
-> tls.setDefaultCACertificates() replaces host default trust roots
-> subsequent host-realm HTTPS client accepts attacker-signed certificates
-> attacker can observe or modify application TLS traffic
The API is present in Node.js 22.19.0 and later in the 22.x line, and Node.js 24.5.0 and later in the 24.x line.
PoC
The attached PoC is fully local. It creates a temporary CA and a loopback HTTPS server signed by that CA, then performs two requests from the host realm.
- Install Node.js 22.19.0 or later in the 22.x line, or Node.js 24.5.0 or later in the 24.x line. OpenSSL must also be available.
- In the attached
pocdirectory, run:
bash
npm install --ignore-scripts
node poc.js
-
A vulnerable result has all of these properties:
-
the first host request fails with a certificate verification error;
- the sandbox reports that it supplied one host-realm CA entry;
- the second host request succeeds with HTTP 200;
- the second response body is
VM2_POC_HOST_TLS_RESPONSE_3e71c8.
The server listens only on loopback and the PoC makes no external request.
Impact
This is an improper sandbox authorization boundary around a process-wide TLS security setting.
An attacker who can submit code to a NodeVM configured with the tls and url builtins can:
- replace the CAs used by subsequent host-side HTTPS and TLS clients;
- make the host authenticate services presenting certificates signed by the attacker;
- intercept host credentials, API tokens, session data, request bodies, and responses when the attacker can influence DNS, routing, a proxy, or a later request destination;
- modify trusted responses, including configuration, webhook, update, identity, and package-retrieval traffic;
- remove the normal trusted roots and cause unrelated host TLS connections to fail.
The attacker does not obtain a direct file or command-execution primitive from this PoC. The critical impact is control of the host process's authentication trust decision, outside the sandbox's authority. Connections that explicitly provide their own CA list are not affected, and already cached TLS sessions may remain unchanged.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.11.6"
},
"package": {
"ecosystem": "npm",
"name": "vm2"
},
"ranges": [
{
"events": [
{
"introduced": "3.11.3"
},
{
"fixed": "3.11.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-92941"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-01T15:27:28Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "Summary\n\nvm2 3.11.6 exposes the host `tls` module to a `NodeVM` when that builtin is explicitly allowed. Although the module object is wrapped as read-only, its functions still execute against process-wide host state. On Node.js versions that provide `tls.setDefaultCACertificates()`, sandbox code can replace the certificate authorities trusted by subsequent host-realm TLS clients.\n\nThe exploit needs only the narrowly allowed `tls` and `url` builtins. It does not require `fs`, `process`, `module`, `child_process`, an external package, or a general `\u0027*\u0027` builtin grant. A host HTTPS request rejected an attacker certificate before sandbox execution, then accepted the same certificate and returned an application marker after the sandbox replaced the default CA list.\n\nThis crosses the intended sandbox boundary. An attacker can make host HTTPS clients trust an attacker-controlled CA, enabling credential theft and response tampering when the attacker can influence a subsequent destination or network path. Replacing the list also removes the normal trust roots, disrupting unrelated host TLS traffic.\n\n### Details\n\nThe vulnerable boundary is the default builtin loader in `lib/builtin.js`. Builtins that are not classified as dangerous are exposed through a recursive read-only bridge:\n\n```js\nbuiltins.set(key, special ? special : vm =\u003e vm.readonly(hostRequire(key)));\n```\n\nThe read-only wrapper prevents ordinary property assignment through the sandbox proxy. It does not make calls such as `tls.setDefaultCACertificates()` sandbox-local. That function changes the default CA list for the current Node.js thread and affects subsequent TLS connections that do not provide their own `ca` option.\n\nThe dangerous-builtin list now rejects `dns` because `dns.setServers()` mutates process-wide host networking state. It does not reject `tls`, even though current Node.js exposes an equivalent process-wide trust mutation through it.\n\nA direct call with a normal sandbox array is not necessary. The native TLS function requires an actual host-realm array. The allowed host `url` module provides one:\n\n```js\nconst tls = require(\u0027tls\u0027);\nconst {URLSearchParams} = require(\u0027url\u0027);\n\nconst hostArray = new URLSearchParams(\n \u0027ca=\u0027 + encodeURIComponent(attackerCaPem)\n).getAll(\u0027ca\u0027);\n\ntls.setDefaultCACertificates(hostArray);\n```\n\n`URLSearchParams.getAll()` executes in the host realm and returns a host array containing the attacker-controlled PEM string. vm2 maps that array into the sandbox. When the mapped value is passed back to the TLS function, the bridge unwraps it to the original host array, satisfying the native type check. The TLS function then replaces the host thread\u0027s default CA set.\n\nThe complete exploit flow is:\n\n```text\nattacker-controlled NodeVM program\n -\u003e require only the allowed tls and url builtins\n -\u003e URLSearchParams.getAll() creates a host array containing attacker CA PEM\n -\u003e bridge unwraps the mapped array when passed back to tls\n -\u003e tls.setDefaultCACertificates() replaces host default trust roots\n -\u003e subsequent host-realm HTTPS client accepts attacker-signed certificates\n -\u003e attacker can observe or modify application TLS traffic\n```\n\nThe API is present in Node.js 22.19.0 and later in the 22.x line, and Node.js 24.5.0 and later in the 24.x line.\n\n### PoC\n\nThe attached PoC is fully local. It creates a temporary CA and a loopback HTTPS server signed by that CA, then performs two requests from the host realm.\n\n1. Install Node.js 22.19.0 or later in the 22.x line, or Node.js 24.5.0 or later in the 24.x line. OpenSSL must also be available.\n2. In the attached `poc` directory, run:\n\n ```bash\n npm install --ignore-scripts\n node poc.js\n ```\n\n3. A vulnerable result has all of these properties:\n\n - the first host request fails with a certificate verification error;\n - the sandbox reports that it supplied one host-realm CA entry;\n - the second host request succeeds with HTTP 200;\n - the second response body is `VM2_POC_HOST_TLS_RESPONSE_3e71c8`.\n\nThe server listens only on loopback and the PoC makes no external request.\n\n### Impact\n\nThis is an improper sandbox authorization boundary around a process-wide TLS security setting.\n\nAn attacker who can submit code to a `NodeVM` configured with the `tls` and `url` builtins can:\n\n- replace the CAs used by subsequent host-side HTTPS and TLS clients;\n- make the host authenticate services presenting certificates signed by the attacker;\n- intercept host credentials, API tokens, session data, request bodies, and responses when the attacker can influence DNS, routing, a proxy, or a later request destination;\n- modify trusted responses, including configuration, webhook, update, identity, and package-retrieval traffic;\n- remove the normal trusted roots and cause unrelated host TLS connections to fail.\n\nThe attacker does not obtain a direct file or command-execution primitive from this PoC. The critical impact is control of the host process\u0027s authentication trust decision, outside the sandbox\u0027s authority. Connections that explicitly provide their own CA list are not affected, and already cached TLS sessions may remain unchanged.",
"id": "GHSA-98xx-8mx4-x7cm",
"modified": "2026-10-01T15:27:28Z",
"published": "2026-10-01T15:27:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-98xx-8mx4-x7cm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92941"
},
{
"type": "WEB",
"url": "https://github.com/patriksimek/vm2/commit/aa146a77f859325e079f3bfbfe6d8309af483daa"
},
{
"type": "PACKAGE",
"url": "https://github.com/patriksimek/vm2"
},
{
"type": "WEB",
"url": "https://github.com/patriksimek/vm2/releases/tag/v3.11.7"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/vm2-3.11.3-before-3.11.7-tls-trust-store-manipulation"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "vm2 NodeVM can replace the host process TLS trust store"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.