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

CVE-2026-58482 is an authentication bypass flaw in Network-AI's ApprovalInbox that allows unauthenticated attackers to approve high-risk operations, bypassing human-in-the-loop controls. This article covers technical details, affected versions from 5.0.0 to 5.12.1, impact analysis, and mitigation strategies.

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

text

// 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