CVE-2026-47683: Vm2 Vm2's BufferAllocLimit Cap Bypassed By Vulnerability
HIGHCVE-2026-47683 is a HIGH vm2's bufferalloclimit cap bypassed by vulnerability (CWE-770: Allocation of Resources Without Limits or Throttling) affecting Vm2 libraries in the npm ecosystem. The issue involves vm2's bufferalloclimit cap bypassed by buffer.concat and buffer.from arraylike. Remediation is available by upgrading affected packages to version 3.11.6.
CVE-2026-47683 at a Glance
How to Fix CVE-2026-47683
To remediate this vulnerability, upgrade all affected Vm2 dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
npm install vm2@3.11.6
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
npm ls vm2
How to Check if You Are Affected
To determine whether your Node.js application is affected by CVE-2026-47683, inspect your project dependencies using npm:
npm ls vm2
Analyze the terminal output to locate any version of Vm2 in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.11.6), your application is affected.
Note: The npm ls vm2 command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-770: Allocation of Resources Without Limits or Throttling, where the product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. In Vm2, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
CVE-2026-47683 Affected Vm2 Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
vm2
|
npm |
< 3.11.6
|
3.11.6
|
References
Frequently Asked Questions
What is CVE-2026-47683?
Which Vm2 versions are affected?
What version fixes CVE-2026-47683?
Is vm2 affected?
What CWE is associated with CVE-2026-47683?
How can I check npm dependencies for CVE-2026-47683?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-gmc2-2x9w-cgh9",
"modified" : "2026-08-17T17:32:10Z",
"published" : "2026-08-17T17:32:10Z",
"aliases" : [ "CVE-2026-47683" ],
"summary" : "vm2's bufferAllocLimit cap bypassed by Buffer.concat and Buffer.from arrayLike",
"details" : "## Summary\n\nvm2 bufferAllocLimit cap bypassed by Buffer.concat and Buffer.from arrayLike\n\nThe `bufferAllocLimit` option introduced in 3.11.0 (GHSA-6785-pvv7-mvg7) caps host-side Buffer allocations driven by sandbox code, the way embedders opt into `timeout`. The cap wraps `Buffer.alloc`, `Buffer.allocUnsafe`, `Buffer.allocUnsafeSlow`, and the deprecated `Buffer(N)` / `new Buffer(N)` forms. Two other API paths reach the same host C++ allocator with an attacker-controlled size and are not capped: `Buffer.concat(list, totalLength)` and `Buffer.from(arrayLike)` with a fake `length`. Sandbox code can use either to allocate an arbitrary number of host external bytes in a single call, defeating the explicit DoS mitigation the embedder configured.\n\n## Details\n\n`lib/setup-sandbox.js` installs `checkBufferAllocLimit` at every wrapped entry to host Buffer allocation:\n\n- `alloc()` at `lib/setup-sandbox.js:474` and the `connect(alloc, host.Buffer.alloc)` at line 480.\n- `allocUnsafe()` at line 488 and `connect(allocUnsafe, host.Buffer.allocUnsafe)` at line 496.\n- `allocUnsafeSlow()` at line 504 and `connect(allocUnsafeSlow, host.Buffer.allocUnsafeSlow)` at line 510.\n- `BufferHandler.apply` at line 424 and `BufferHandler.construct` at line 433 for the deprecated `Buffer(N)` / `new Buffer(N)` numeric-first-arg paths.\n\n`Buffer.concat` is not wrapped. The sandbox-visible `Buffer.concat` is therefore the bridge proxy of the host `Buffer.concat`, which calls into Node's `Buffer.allocUnsafe(totalLength)` internally without going through the sandbox-side `allocUnsafe` wrapper. Same for `Buffer.from` when the argument is array-like (`{length: N}`): Node's `fromArrayLike` allocates a buffer of size `N` before the iteration that fills it. Neither of those allocator paths consult `localBufferAllocLimit`.\n\nThe mitigation rationale documented in `docs/ATTACKS.md` Category 23 explicitly enumerates the surfaces that were considered and either capped (Buffer.alloc family) or punted to follow-up (`new Uint8Array(N)`, `new ArrayBuffer(N)`, `String.prototype.repeat`). `Buffer.concat(list, totalLength)` is not listed in either group, and `Buffer.from(arrayLike)` is mentioned only as \"bounded by source array size which had to be allocated through some other path first\" -- which is not true for the `{length: N}` form, because no array of length `N` actually exists.\n\nA single call from sandbox to `Buffer.concat([Buffer.from('a')], 50 * 1024 * 1024)` allocates 50 MiB of host external memory. The allocation itself is a single synchronous host C++ call that `timeout` cannot interrupt, exactly like the original advisory. The zero-fill that follows is interruptible, but the memory is already committed by the time the interrupt could fire, so the embedder's container memory budget is the only ceiling. The same pattern in a loop, or with a larger `totalLength`, drives RSS up by hundreds of megabytes per call.\n\nThe fix uses the existing `checkBufferAllocLimit(size)` helper and a sandbox-side wrapper installed via `connect(...)` -- one for `Buffer.concat` that sums the `totalLength` (or falls back to summing list lengths) and one for `Buffer.from` that recognises the array-like-with-numeric-`length` branch.\n\n## PoC\n\n```javascript\n'use strict';\nconst { VM, NodeVM } = require('vm2');\n\nfunction ext() { return Math.round(process.memoryUsage().external / 1024 / 1024); }\nfunction tryBypass(label, code) {\n const ext0 = ext();\n let buf;\n try { buf = code(); }\n catch (e) {\n console.log(`[${label}] CAPPED -- ${String(e).split('\\n')[0]}`);\n return;\n }\n console.log(`[${label}] BYPASSED -- got ${buf && buf.length} bytes (external +${ext() - ext0} MB)`);\n}\n\nconsole.log('Cap is configured at 1024 bytes.\\n');\n\nconst vm1 = new VM({ bufferAllocLimit: 1024 });\ntryBypass('VM Buffer.alloc(50MB) ',\n () => vm1.run('Buffer.alloc(50 * 1024 * 1024)'));\n\nconst vm2 = new VM({ bufferAllocLimit: 1024 });\ntryBypass('VM Buffer.concat 50MB ',\n () => vm2.run('Buffer.concat([Buffer.from(\"a\")], 50 * 1024 * 1024)'));\n\nconst vm3 = new NodeVM({ bufferAllocLimit: 1024 });\ntryBypass('NodeVM Buffer.concat 50MB ',\n () => vm3.run('module.exports = Buffer.concat([Buffer.from(\"a\")], 50 * 1024 * 1024);'));\n\nconst vm4 = new VM({ bufferAllocLimit: 1024 });\ntryBypass('VM Buffer.from({length: 8MB})',\n () => vm4.run('Buffer.from({length: 8 * 1024 * 1024})'));\n```\n\nRun with `node poc.js` against `vm2@3.11.3`:\n\n```\nCap is configured at 1024 bytes.\n\n[VM Buffer.alloc(50MB) ] CAPPED -- RangeError: Buffer allocation size 52428800 exceeds bufferAllocLimit 1024\n[VM Buffer.concat 50MB ] BYPASSED -- got 52428800 bytes (external +50 MB)\n[NodeVM Buffer.concat 50MB ] BYPASSED -- got 52428800 bytes (external +50 MB)\n[VM Buffer.from({length: 8MB})] BYPASSED -- got 8388608 bytes (external +8 MB)\n```\n\nProcess RSS climbs by the same amount each call, confirming a real host C++ allocation rather than a sandbox-realm-only effect.\n\n## Impact\n\nThis is the same DoS class GHSA-6785-pvv7-mvg7 was filed for: untrusted sandbox code amplifying a small payload into a large synchronous host external-memory allocation that V8's `timeout` cannot preempt. In the environments the advisory cites -- Docker memory limits, Kubernetes pods, AWS Lambda -- a single 200-byte sandbox payload can drive a multi-hundred-megabyte RSS jump and OOM the host process.\n\nThe Category 23 fix was specifically scoped to \"cap host Buffer external allocation\" and embedders are documented to opt into `bufferAllocLimit` as their layered defense against this class. The two paths above are uncapped, so an embedder that has configured `bufferAllocLimit: 32 * 1024 * 1024` (the value recommended in the README's Hardening recommendations) is still vulnerable to the exact attack the option was designed to prevent. The mitigation invariant -- \"every Buffer external allocation driven by sandbox code is capped by `bufferAllocLimit`\" -- does not hold.\n\nNo sandbox escape; pure DoS.",
"severity" : [ {
"type" : "CVSS_V4",
"score" : "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "npm",
"name" : "vm2"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "3.11.6"
} ]
} ],
"database_specific" : {
"last_known_affected_version_range" : "<= 3.11.5"
}
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/patriksimek/vm2/security/advisories/GHSA-gmc2-2x9w-cgh9"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/patriksimek/vm2"
}, {
"type" : "WEB",
"url" : "https://github.com/patriksimek/vm2/releases/tag/3.11.6"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-770" ],
"severity" : "HIGH",
"github_reviewed" : true,
"github_reviewed_at" : "2026-08-17T17:32:10Z",
"nvd_published_at" : null
}
}