CVE-2026-58482

Network-AI, a TypeScript/Node.js multi-agent orchestrator, has a shipped, exported, documented feature called ApprovalInbox (lib/approval-inbox.ts). It is the network surface of the human-in-the-loop Approval Gate, which ApprovalGate uses to require explicit human approval for high-risk operations. The HTTP server it exposes has no authentication of any kind and sets Access-Control-Allow-Origin: * on every route, including the state-changing POST /approvals/:id/approve and /deny. As a result, in versions 5.0.0 through 5.12.1, any party who can send an HTTP request to the inbox port — a co-located process, a container/SSRF on the same host, a remote client when the operator binds a non-loopback address, or any website the operator visits in a browser (via the wildcard CORS) — can enumerate pending approvals and approve them, defeating the entire human-in-the-loop control and causing the gated high-risk action (e.g. a shell command the agent was holding for review) to execute without consent. This issue is fixed in v5.12.2. ApprovalInbox now accepts a secret option. When set, the mutating endpoints POST /:id/approve and POST /:id/deny require an Authorization: Bearer <secret> header, validated in constant time with crypto.timingSafeEqual. startServer() already binds to 127.0.0.1 by default; operators exposing the inbox on a network must set a secret.

Network-AI, a TypeScript/Node.js multi-agent orchestrator, has a shipped, exported, documented feature called ApprovalInbox (lib/approval-inbox.ts). It is the network surface of the human-in-the-loop Approval Gate, which ApprovalGate uses to require explicit human approval for high-risk operations. The HTTP server it exposes has no authentication of any kind and sets Access-Control-Allow-Origin: * on every route, including the state-changing POST /approvals/:id/approve and /deny. As a result, in versions 5.0.0 through 5.12.1, any party who can send an HTTP request to the inbox port — a co-located process, a container/SSRF on the same host, a remote client when the operator binds a non-loopback address, or any website the operator visits in a browser (via the wildcard CORS) — can enumerate pending approvals and approve them, defeating the entire human-in-the-loop control and causing the gated high-risk action (e.g. a shell command the agent was holding for review) to execute without consent. This issue is fixed in v5.12.2. ApprovalInbox now accepts a secret option. When set, the mutating endpoints POST /:id/approve and POST /:id/deny require an Authorization: Bearer <secret> header, validated in constant time with crypto.timingSafeEqual. startServer() already binds to 127.0.0.1 by default; operators exposing the inbox on a network must set a secret.

Summary

network-ai's ApprovalInbox (lib/approval-inbox.ts) is a shipped, exported, documented feature — "a web-accessible approval queue with REST API … and SSE streaming" (SECURITY.md). It is the network surface of the human-in-the-loop Approval Gate, which ApprovalGate uses to require explicit human approval for "high-risk operations (writes, shell commands, budget spend)" (SECURITY.md). The HTTP server it exposes has no authentication of any kind and sets Access-Control-Allow-Origin: * on every route, including the state-changing POST /approvals/:id/approve and /deny.

As a result, any party who can send an HTTP request to the inbox port — a co-located process, a container/SSRF on the same host, a remote client when the operator binds a non-loopback address, or any website the operator visits in a browser (via the wildcard CORS) — can enumerate pending approvals and approve them, defeating the entire human-in-the-loop control and causing the gated high-risk action (e.g. a shell command the agent was holding for review) to execute without consent.

This is the same vulnerability class the maintainer has already fixed twice on the MCP server (GHSA-fj4g-2p96-q6m3 missing auth; GHSA-j3vx-cx2r-pvg8 empty default secret) — the auxiliary ApprovalInbox server never received that hardening.

• Affected: network-ai <= 5.11.0 (current latest), lib/approval-inbox.ts — httpHandler() / routeRequest() / startServer(). ApprovalInbox is public API (exported from index.ts:1126).
• CWE: CWE-862 (Missing Authorization) + CWE-352 (Cross-Site Request Forgery, via wildcard CORS).
• CVSS v3.1 (proposed):
  • Drive-by CSRF against the default 127.0.0.1 deployment: AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N = 5.9 Medium.
  • Direct request when the operator binds a non-loopback address (or local/SSRF reach): AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N = 8.1 High.

Details

No authentication on the request pipeline (lib/approval-inbox.ts)

httpHandler() sets a wildcard CORS policy and routes every request straight to routeRequest() with no auth check:

// lib/approval-inbox.ts:250-275
httpHandler() {
  return (req, res) => {
    ...
    res.setHeader('Access-Control-Allow-Origin', '*');          // 256  <-- wildcard CORS
    res.setHeader('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
    res.setHeader('Access-Control-Allow-Headers', 'Content-Type');
    if (req.method === 'OPTIONS') { res.writeHead(204); res.end(); return; }   // preflight OK for any origin
    ...
    this.routeRequest(req, res, subPath, url);                  // 273  <-- no token / secret / origin gate
  };
}

routeRequest() exposes list + approve/deny with no credential check (default pathPrefix = /approvals):

// lib/approval-inbox.ts:369-405
routeRequest(req, res, subPath, url) {
  if (subPath === '/' && req.method === 'GET') {                       // GET /approvals/  -> enumerate pending ids
    this.sendJson(res, 200, this.list(status)); return;
  }
  ...
  const approveMatch = subPath.match(/^\/([a-f0-9]+)\/approve$/);      // POST /approvals/:id/approve
  if (approveMatch && req.method === 'POST') {
    this.readBody(req).then((body) => {
      const approvedBy = typeof body.approvedBy === 'string' ? body.approvedBy : 'anonymous';  // defaults to 'anonymous'
      const entry = this.approve(approveMatch[1], approvedBy, reason);  // resolves the gate -> action proceeds
      ...
    });
  }
}

approve() resolves the pending promise that ApprovalGate is awaiting, so the gated action proceeds:

// lib/approval-inbox.ts:172-183 / 327-339
approve(id, approvedBy, reason) {
  ...
  return this.resolve(id, 'approved', { approved: true, approvedBy, reason });  // promise -> {approved:true}
}

startServer() binds the handler (default…

Network-AI, a TypeScript/Node.js multi-agent orchestrator, has a shipped, exported, documented feature called ApprovalInbox (lib/approval-inbox.ts). It is the network surface of the human-in-the-loop Approval Gate, which ApprovalGate uses to require explicit human approval for high-risk operations. The HTTP server it exposes has no authentication of any kind and sets Access-Control-Allow-Origin: * on every route, including the state-changing POST /approvals/:id/approve and /deny. As a result, in versions 5.0.0 through 5.12.1, any party who can send an HTTP request to the inbox port — a co-located process, a container/SSRF on the same host, a remote client when the operator binds a non-loopback address, or any website the operator visits in a browser (via the wildcard CORS) — can enumerate pending approvals and approve them, defeating the entire human-in-the-loop control and causing the gated high-risk action (e.g. a shell command the agent was holding for review) to execute without consent. This issue is fixed in v5.12.2. ApprovalInbox now accepts a secret option. When set, the mutating endpoints POST /:id/approve and POST /:id/deny require an Authorization: Bearer <secret> header, validated in constant time with crypto.timingSafeEqual. startServer() already binds to 127.0.0.1 by default; operators exposing the inbox on a network must set a secret.

Network-AI, a TypeScript/Node.js multi-agent orchestrator, has a shipped, exported, documented feature called ApprovalInbox (lib/approval-inbox.ts). It is the network surface of the human-in-the-loop Approval Gate, which ApprovalGate uses to require explicit human approval for high-risk operations. The HTTP server it exposes has no authentication of any kind and sets Access-Control-Allow-Origin: * on every route, including the state-changing POST /approvals/:id/approve and /deny. As a result, in versions 5.0.0 through 5.12.1, any party who can send an HTTP request to the inbox port — a co-located process, a container/SSRF on the same host, a remote client when the operator binds a non-loopback address, or any website the operator visits in a browser (via the wildcard CORS) — can enumerate pending approvals and approve them, defeating the entire human-in-the-loop control and causing the gated high-risk action (e.g. a shell command the agent was holding for review) to execute without consent. This issue is fixed in v5.12.2. ApprovalInbox now accepts a secret option. When set, the mutating endpoints POST /:id/approve and POST /:id/deny require an Authorization: Bearer <secret> header, validated in constant time with crypto.timingSafeEqual. startServer() already binds to 127.0.0.1 by default; operators exposing the inbox on a network must set a secret.

Summary

network-ai's ApprovalInbox (lib/approval-inbox.ts) is a shipped, exported, documented feature — "a web-accessible approval queue with REST API … and SSE streaming" (SECURITY.md). It is the network surface of the human-in-the-loop Approval Gate, which ApprovalGate uses to require explicit human approval for "high-risk operations (writes, shell commands, budget spend)" (SECURITY.md). The HTTP server it exposes has no authentication of any kind and sets Access-Control-Allow-Origin: * on every route, including the state-changing POST /approvals/:id/approve and /deny.

As a result, any party who can send an HTTP request to the inbox port — a co-located process, a container/SSRF on the same host, a remote client when the operator binds a non-loopback address, or any website the operator visits in a browser (via the wildcard CORS) — can enumerate pending approvals and approve them, defeating the entire human-in-the-loop control and causing the gated high-risk action (e.g. a shell command the agent was holding for review) to execute without consent.

This is the same vulnerability class the maintainer has already fixed twice on the MCP server (GHSA-fj4g-2p96-q6m3 missing auth; GHSA-j3vx-cx2r-pvg8 empty default secret) — the auxiliary ApprovalInbox server never received that hardening.

• Affected: network-ai <= 5.11.0 (current latest), lib/approval-inbox.ts — httpHandler() / routeRequest() / startServer(). ApprovalInbox is public API (exported from index.ts:1126).
• CWE: CWE-862 (Missing Authorization) + CWE-352 (Cross-Site Request Forgery, via wildcard CORS).
• CVSS v3.1 (proposed):
  • Drive-by CSRF against the default 127.0.0.1 deployment: AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N = 5.9 Medium.
  • Direct request when the operator binds a non-loopback address (or local/SSRF reach): AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N = 8.1 High.

Details

No authentication on the request pipeline (lib/approval-inbox.ts)

httpHandler() sets a wildcard CORS policy and routes every request straight to routeRequest() with no auth check:

// lib/approval-inbox.ts:250-275
httpHandler() {
  return (req, res) => {
    ...
    res.setHeader('Access-Control-Allow-Origin', '*');          // 256  <-- wildcard CORS
    res.setHeader('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
    res.setHeader('Access-Control-Allow-Headers', 'Content-Type');
    if (req.method === 'OPTIONS') { res.writeHead(204); res.end(); return; }   // preflight OK for any origin
    ...
    this.routeRequest(req, res, subPath, url);                  // 273  <-- no token / secret / origin gate
  };
}

routeRequest() exposes list + approve/deny with no credential check (default pathPrefix = /approvals):

// lib/approval-inbox.ts:369-405
routeRequest(req, res, subPath, url) {
  if (subPath === '/' && req.method === 'GET') {                       // GET /approvals/  -> enumerate pending ids
    this.sendJson(res, 200, this.list(status)); return;
  }
  ...
  const approveMatch = subPath.match(/^\/([a-f0-9]+)\/approve$/);      // POST /approvals/:id/approve
  if (approveMatch && req.method === 'POST') {
    this.readBody(req).then((body) => {
      const approvedBy = typeof body.approvedBy === 'string' ? body.approvedBy : 'anonymous';  // defaults to 'anonymous'
      const entry = this.approve(approveMatch[1], approvedBy, reason);  // resolves the gate -> action proceeds
      ...
    });
  }
}

approve() resolves the pending promise that ApprovalGate is awaiting, so the gated action proceeds:

// lib/approval-inbox.ts:172-183 / 327-339
approve(id, approvedBy, reason) {
  ...
  return this.resolve(id, 'approved', { approved: true, approvedBy, reason });  // promise -> {approved:true}
}

startServer() binds the handler (default…