CVE-2026-58482: Network-AI Auth Bypass Vulnerability

CVE-2026-58482 Overview

Network-AI, a TypeScript/Node.js multi-agent orchestrator, ships an exported ApprovalInbox feature (lib/approval-inbox.ts) that exposes the human-in-the-loop Approval Gate over HTTP. In versions 5.0.0 through 5.12.1, the inbox server enforces no authentication and returns Access-Control-Allow-Origin: * on every route, including the state-changing POST /approvals/:id/approve and POST /approvals/:id/deny endpoints. Any party able to reach the inbox port can enumerate pending approvals and approve gated high-risk operations without operator consent [CWE-352]. The issue is fixed in v5.12.2.

Critical Impact

Attackers can bypass the human-in-the-loop Approval Gate and trigger arbitrary gated actions, such as shell commands the agent held for review.

Affected Products

• Network-AI versions 5.0.0 through 5.12.1
• ApprovalInbox component (lib/approval-inbox.ts)
• Deployments binding the inbox to a non-loopback address or co-located with untrusted processes

Discovery Timeline

• 2026-07-20 - CVE-2026-58482 published to NVD
• 2026-07-21 - Last updated in NVD database

Technical Details for CVE-2026-58482

Vulnerability Analysis

The ApprovalInbox HTTP server is the network surface of Network-AI's Approval Gate. The Approval Gate exists to require explicit human approval before an agent executes high-risk operations, such as a shell command staged for review. In vulnerable releases, the mutating endpoints POST /approvals/:id/approve and POST /approvals/:id/deny accept requests with no credential check. The server also emits Access-Control-Allow-Origin: * on every route, allowing cross-origin browsers to issue state-changing requests.

An attacker who can send an HTTP request to the inbox port can list pending approvals and approve them. This defeats the human-in-the-loop control entirely and causes the gated action to execute without operator consent.

Root Cause

The root cause is missing authentication on state-changing HTTP endpoints combined with a permissive wildcard CORS policy. There is no bearer token, no origin allowlist, and no CSRF token binding the request to a legitimate operator session [CWE-352].

Attack Vector

Exploitation paths include a co-located process on the same host, a container or Server-Side Request Forgery (SSRF) primitive reaching the inbox port, a remote client when the operator binds a non-loopback address, or any website an operator visits in a browser using the wildcard CORS to forge approve requests cross-origin. The attacker enumerates pending approvals and issues POST /approvals/:id/approve to release the gated high-risk action.

See the GitHub Security Advisory GHSA-mxjx-28vx-xjjj for the maintainer's technical description.

Detection Methods for CVE-2026-58482

Indicators of Compromise

• Approval Gate audit log entries showing approvals that no operator recalls issuing
• HTTP access logs for the inbox port containing POST /approvals/:id/approve requests without an Authorization header
• Requests to the inbox port originating from unexpected Origin or Referer headers, including browser origins operators visited
• Executions of gated shell commands with timestamps that do not correlate with human review activity

Detection Strategies

• Inventory Network-AI installations and identify any running version in the 5.0.0 through 5.12.1 range
• Verify the network binding of ApprovalInbox and flag any instance not bound to 127.0.0.1
• Inspect reverse-proxy and application logs for approve/deny calls that lack a bearer token
• Correlate Approval Gate decisions with operator identity records to detect anomalies

Monitoring Recommendations

• Alert on any POST to /approvals/:id/approve or /approvals/:id/deny missing an Authorization: Bearer header
• Monitor for outbound connections or process launches triggered by the agent that were not preceded by a verified operator approval
• Log the source IP, origin, and user-agent for every inbox request and review for cross-origin abuse

How to Mitigate CVE-2026-58482

Immediate Actions Required

• Upgrade Network-AI to v5.12.2 or later
• Configure the ApprovalInboxsecret option and require Authorization: Bearer <secret> on all clients
• Ensure startServer() remains bound to 127.0.0.1 unless a secret is configured and network exposure is intentional
• Review Approval Gate audit history for approvals issued during the vulnerable period

Patch Information

The fix is available in Network-AI 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. Refer to the GitHub Release v5.12.2 and the remediation commit.

Workarounds

• Keep the inbox bound to the loopback interface 127.0.0.1 and never expose it on a routable address
• Place the inbox behind a reverse proxy that enforces authentication and an explicit Origin allowlist
• Restrict host access so no untrusted co-located process or container can reach the inbox port
• Disable browser access by removing wildcard CORS at the proxy layer

// Patch reference: version bump from 5.12.1 to 5.12.2
// .claude-plugin/marketplace.json and .claude-plugin/plugin.json
-      "version": "5.12.1",
+      "version": "5.12.2",
// Source: https://github.com/Jovancoding/Network-AI/commit/a59c13a1f0ce0e8a0779a90343eef92fac5ab4c3