GHSA-mxjx-28vx-xjjj: Network-AI: ApprovalInbox HTTP server has no authentication — anyone can approve pending agent actions

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.