CVE-2026-57135

PraisonAI is a multi-agent teams system. From 1.2.3 until 1.7.2, SandboxExecutor network-isolated mode in src/praisonai-ts/src/cli/features/sandbox-executor.ts uses buildEnv() only to inject invalid http_proxy and https_proxy environment variables and does not establish an operating-system network boundary. Programs that ignore those proxy variables can open sockets directly, allowing supposedly isolated commands to reach localhost, internal services, cloud metadata, or external hosts and potentially exfiltrate data. An initial remediation was released in version 1.7.2.

PraisonAI is a multi-agent teams system. From 1.2.3 until 1.7.2, SandboxExecutor network-isolated mode in src/praisonai-ts/src/cli/features/sandbox-executor.ts uses buildEnv() only to inject invalid http_proxy and https_proxy environment variables and does not establish an operating-system network boundary. Programs that ignore those proxy variables can open sockets directly, allowing supposedly isolated commands to reach localhost, internal services, cloud metadata, or external hosts and potentially exfiltrate data. An initial remediation was released in version 1.7.2.

Summary

The published npm package praisonai exports a TypeScript SandboxExecutor with a network-isolated mode. The CLI lists that mode as:

network-isolated  No network access (proxy blocked)

The implementation does not create a network namespace, firewall rule, socket filter, or proxy-enforced execution boundary. It only injects proxy environment variables into the child process:

http_proxy: 'http://localhost:0',
https_proxy: 'http://localhost:0',
HTTP_PROXY: 'http://localhost:0',
HTTPS_PROXY: 'http://localhost:0',
no_proxy: '',
NO_PROXY: ''

Clients that do not explicitly honor those proxy variables continue to use the host network stack. A local-only PoV shows that, inside mode: "network-isolated", a proxy-aware Node invocation is stopped, while a plain Node HTTP client reaches a loopback HTTP server from the same sandboxed command environment.

This is a network-isolation protection failure in an exported npm API and CLI mode. It is not a generic claim that every PraisonAI sandbox backend is affected.

Technical Details

src/praisonai-ts/src/cli/features/sandbox-executor.ts declares the mode:

export type SandboxMode = 'disabled' | 'basic' | 'strict' | 'network-isolated';

SandboxExecutor.spawn() starts the command through the host shell and passes only the environment returned by buildEnv():

const proc = spawn('sh', ['-c', command], {
  cwd: this.config.cwd,
  env,
  timeout: this.config.timeout,
  stdio: ['pipe', 'pipe', 'pipe']
});

For network-isolated, buildEnv() does not apply an OS-level network restriction. It only sets proxy variables:

case 'network-isolated':
  // No network access (requires additional OS-level setup)
  return {
    ...baseEnv,
    http_proxy: 'http://localhost:0',
    https_proxy: 'http://localhost:0',
    HTTP_PROXY: 'http://localhost:0',
    HTTPS_PROXY: 'http://localhost:0',
    no_proxy: '',
    NO_PROXY: ''
  };

The CLI mode listing presents this as no network access:

'network-isolated': 'No network access (proxy blocked)'

That creates a false boundary. Proxy variables affect only clients that choose to read and honor them. Other clients can still open sockets directly from the child process.

Why This Is Not Intended Behavior

The vulnerable behavior is not "commands can run." The issue is that a mode named network-isolated and displayed to users as "No network access" still allows direct socket access.

The source comment says network-isolated requires additional OS-level setup, which is consistent with the finding: proxy variables alone are not a network isolation mechanism. The exported npm API and CLI mode do not provide such setup or warn callers that this mode is only a best-effort proxy hint.

If the intended behavior is merely "set proxy variables for cooperative clients," the mode name and CLI description should be changed so users do not rely on it as a security boundary.

PoV

Run from a local reproduction checkout:

node poc/pov_poc.js 1.7.1

The PoV:

1. Installs npm:[email protected] into a temporary project.
2. Starts a harmless HTTP server bound to 127.0.0.1 on a random local port.
3. Creates new SandboxExecutor({ mode: "network-isolated" }).
4. Confirms the child environment contains the proxy variables.
5. Runs node --use-env-proxy client.js as a proxy-aware control. It fails and does not reach the server.
6. Runs node client.js without proxy opt-in. It reaches the server and prints the marker.

Observed output summary from evidence/pov-npm-1.7.1.json:

{
  "version": "1.7.1",
  "mode": "network-isolated",
  "control": {
    "localServerBoundToLoopback": true,
    "proxyVariablesSet": true,
    "proxyAwareClientStopped": true,
    "requestReachedLoopbackServer": true
  },
  "observed": {
    "proxyAwareRun": {
      "success": false,
      "stdout": "",
      "exitCode": 2
    },
    "netRun": {
      "success": true,
      "stdout":…

PraisonAI is a multi-agent teams system. From 1.2.3 until 1.7.2, SandboxExecutor network-isolated mode in src/praisonai-ts/src/cli/features/sandbox-executor.ts uses buildEnv() only to inject invalid http_proxy and https_proxy environment variables and does not establish an operating-system network boundary. Programs that ignore those proxy variables can open sockets directly, allowing supposedly isolated commands to reach localhost, internal services, cloud metadata, or external hosts and potentially exfiltrate data. An initial remediation was released in version 1.7.2.

PraisonAI is a multi-agent teams system. From 1.2.3 until 1.7.2, SandboxExecutor network-isolated mode in src/praisonai-ts/src/cli/features/sandbox-executor.ts uses buildEnv() only to inject invalid http_proxy and https_proxy environment variables and does not establish an operating-system network boundary. Programs that ignore those proxy variables can open sockets directly, allowing supposedly isolated commands to reach localhost, internal services, cloud metadata, or external hosts and potentially exfiltrate data. An initial remediation was released in version 1.7.2.

Summary

The published npm package praisonai exports a TypeScript SandboxExecutor with a network-isolated mode. The CLI lists that mode as:

network-isolated  No network access (proxy blocked)

The implementation does not create a network namespace, firewall rule, socket filter, or proxy-enforced execution boundary. It only injects proxy environment variables into the child process:

http_proxy: 'http://localhost:0',
https_proxy: 'http://localhost:0',
HTTP_PROXY: 'http://localhost:0',
HTTPS_PROXY: 'http://localhost:0',
no_proxy: '',
NO_PROXY: ''

Clients that do not explicitly honor those proxy variables continue to use the host network stack. A local-only PoV shows that, inside mode: "network-isolated", a proxy-aware Node invocation is stopped, while a plain Node HTTP client reaches a loopback HTTP server from the same sandboxed command environment.

This is a network-isolation protection failure in an exported npm API and CLI mode. It is not a generic claim that every PraisonAI sandbox backend is affected.

Technical Details

src/praisonai-ts/src/cli/features/sandbox-executor.ts declares the mode:

export type SandboxMode = 'disabled' | 'basic' | 'strict' | 'network-isolated';

SandboxExecutor.spawn() starts the command through the host shell and passes only the environment returned by buildEnv():

const proc = spawn('sh', ['-c', command], {
  cwd: this.config.cwd,
  env,
  timeout: this.config.timeout,
  stdio: ['pipe', 'pipe', 'pipe']
});

For network-isolated, buildEnv() does not apply an OS-level network restriction. It only sets proxy variables:

case 'network-isolated':
  // No network access (requires additional OS-level setup)
  return {
    ...baseEnv,
    http_proxy: 'http://localhost:0',
    https_proxy: 'http://localhost:0',
    HTTP_PROXY: 'http://localhost:0',
    HTTPS_PROXY: 'http://localhost:0',
    no_proxy: '',
    NO_PROXY: ''
  };

The CLI mode listing presents this as no network access:

'network-isolated': 'No network access (proxy blocked)'

That creates a false boundary. Proxy variables affect only clients that choose to read and honor them. Other clients can still open sockets directly from the child process.

Why This Is Not Intended Behavior

The vulnerable behavior is not "commands can run." The issue is that a mode named network-isolated and displayed to users as "No network access" still allows direct socket access.

The source comment says network-isolated requires additional OS-level setup, which is consistent with the finding: proxy variables alone are not a network isolation mechanism. The exported npm API and CLI mode do not provide such setup or warn callers that this mode is only a best-effort proxy hint.

If the intended behavior is merely "set proxy variables for cooperative clients," the mode name and CLI description should be changed so users do not rely on it as a security boundary.

PoV

Run from a local reproduction checkout:

node poc/pov_poc.js 1.7.1

The PoV:

1. Installs npm:[email protected] into a temporary project.
2. Starts a harmless HTTP server bound to 127.0.0.1 on a random local port.
3. Creates new SandboxExecutor({ mode: "network-isolated" }).
4. Confirms the child environment contains the proxy variables.
5. Runs node --use-env-proxy client.js as a proxy-aware control. It fails and does not reach the server.
6. Runs node client.js without proxy opt-in. It reaches the server and prints the marker.

Observed output summary from evidence/pov-npm-1.7.1.json:

{
  "version": "1.7.1",
  "mode": "network-isolated",
  "control": {
    "localServerBoundToLoopback": true,
    "proxyVariablesSet": true,
    "proxyAwareClientStopped": true,
    "requestReachedLoopbackServer": true
  },
  "observed": {
    "proxyAwareRun": {
      "success": false,
      "stdout": "",
      "exitCode": 2
    },
    "netRun": {
      "success": true,
      "stdout":…