<?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-04T06:11:37.905685+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-92940</id>
    <title>CVE-2026-92940 — vm2 3.11.3 through 3.11.6 HTTPS Credential Exposure via globalAgent</title>
    <updated>2026-10-04T06:11:39.148015+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> patriksimek vm2</p>
<p>vm2 versions 3.11.3 through 3.11.6 expose the host process's real https.globalAgent to sandboxed code when a NodeVM is explicitly configured to allow require('https'). The builtin loader wraps host modules in a read-only proxy, but method calls such as Agent.prototype.on() are forwarded to the underlying host object, so sandbox code can register a listener for the agent's 'free' event. When an unrelated host HTTPS request releases a pooled connection, the listener receives the live host request options and the host TLSSocket, allowing sandboxed code to read the host's Authorization header and private destination host/port, attach a data listener to the released socket and read subsequent host response bodies in plaintext, and issue attacker-chosen authenticated requests using the stolen credentials. The issue is fixed in 3.11.7.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-92940"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-h85j-hv3c-qfgq</id>
    <title>GHSA-h85j-hv3c-qfgq — vm2 exposes host HTTPS credentials and TLS traffic through globalAgent</title>
    <updated>2026-10-04T06:11:39.148164+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: vm2</p>
<p>Summary</p>
<p>vm2 3.11.6 exposes the host process's real `https.globalAgent` when a `NodeVM` is explicitly allowed to require `https`. The module is wrapped as read-only, but calls to methods on the shared agent still mutate the host object. Sandbox code can register a `free` listener and receive host request options and the host TLS socket whenever an unrelated host HTTPS request releases a pooled connection.</p>
<p>In a contained test, sandbox code allowed only the `https` builtin:</p>
<p>- read the host request's bearer token from the agent event;
- attached a data listener to the released host TLS socket and read the next host response body in plaintext;
- learned the private service host and port;
- sent an attacker-chosen authenticated POST using the stolen host token; and
- received confirmation that the service accepted the action.</p>
<p>The host application never passed its credentials, request, response, socket, or destination into the sandbox. They crossed the boundary solely because vm2 exposes the process-global HTTPS agent instead of a sandbox-local network module instance.</p>
<p>### Details</p>
<p>The vulnerable boundary is the default builtin loader in `lib/builtin.js`:</p>
<p>```js
builtins.set(key, special ? special : vm =&gt; vm.readonly(hostRequire(key)));
```</p>
<p>The wrapper recursively exposes properties of the actual host module. For ordinary constants, a read-only proxy can be sufficient. It is not sufficient for process-global EventEmitter objects whose methods mutate internal state.</p>
<p>`https.gl…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-h85j-hv3c-qfgq"/>
  </entry>
</feed>
