<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-05T19:17:01.028842+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-92950</id>
    <title>CVE-2026-92950 — vm2 before 3.11.7 Sandbox Escape via CLI require</title>
    <updated>2026-10-05T19:17:02.453482+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> patriksimek vm2</p>
<p>vm2 before 3.11.7 contains a sandbox escape vulnerability in the CLI tool that allows attackers to execute arbitrary code in the host Node.js process. Attackers can supply a malicious script file to the vm2 CLI that uses require(__filename) to re-execute itself in the host realm, bypassing sandbox isolation and accessing host modules like fs and child_process.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-92950"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-jxxv-8r27-vm4p</id>
    <title>GHSA-jxxv-8r27-vm4p — vm2 CLI provides no sandbox isolation - host-realm require() is reachable from sandboxed scripts</title>
    <updated>2026-10-05T19:17:02.453577+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: vm2</p>
<p>### Summary
The `vm2` command-line tool installed by `npm install -g vm2` and documented in the README's "CLI" section runs the supplied script under `NodeVM` with `require:{external:true}` and no `root` / `context` / `builtin` configured. With these defaults the resolver loads every relative or absolute `require()` target through the **host** `require()` function, executing the attacker's module body in the host Node.js process before the result is ever proxied back into the sandbox. A single attacker-controlled file passed to `vm2 ./script.js` can call `require(__filename)` to re-execute itself in host realm and reach `fs`, `child_process`, etc. The documented sandbox runner is therefore equivalent to `node ./script.js`. No additional files, flags, or user interaction are required.</p>
<p>### Details
The vulnerability lets a **malicious sandboxed script** - the file argument to the documented `vm2 &lt;file&gt;` CLI - execute arbitrary code in the **host Node.js process**, crossing the sandbox → host boundary that vm2 is meant to enforce.</p>
<p>#### Vulnerable code path</p>
<p>1. **Source** - `bin/vm2:3` → `lib/cli.js:7-18`. `process.argv[2]` is the
   attacker-authored script path. The CLI invokes:
   ```js
   NodeVM.file(path, { verbose: true, require: { external: true } });
   ```
   Without `require.root`, `require.context`, nor `require.builtin`.
2. **Hop** - `lib/nodevm.js:618-636`. `NodeVM.file` reads the file and calls
   `new NodeVM(options).run(body, resolvedFilename)`.
3. **Hop** - `li…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-jxxv-8r27-vm4p"/>
  </entry>
</feed>
