Network-AI: ApprovalInbox HTTP server has no authentication — anyone can approve pending agent actions
Summary
| CVE | CVE-2026-58482 |
|---|---|
| State | PUBLISHED |
| Assigner | GitHub_M |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-07-20 17:18:15 UTC |
| Updated | 2026-07-21 19:49:44 UTC |
| Description | 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. |
Risk And Classification
Primary CVSS: v3.1 5.9 MEDIUM from [email protected]
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N
Problem Types: CWE-352 | CWE-862 | CWE-352 CWE-352: Cross-Site Request Forgery (CSRF) | CWE-862 CWE-862: Missing Authorization
| Version | Source | Type | Score | Severity | Vector |
|---|---|---|---|---|---|
| 3.1 | [email protected] | Secondary | 5.9 | MEDIUM | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N |
| 3.1 | CNA | DECLARED | 5.9 | MEDIUM | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N |
CVSS v3.1 Breakdown
Attack Vector
NetworkAttack Complexity
HighPrivileges Required
NoneUser Interaction
RequiredScope
UnchangedConfidentiality
LowIntegrity
HighAvailability
NoneCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | Jovancoding | Network-AI | affected >= 5.0.0, < 5.12.2 | Not specified |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| github.com/Jovancoding/Network-AI/commit/a59c13a1f0ce0e8a0779a90343eef92... | [email protected] | github.com | |
| github.com/Jovancoding/Network-AI/releases/tag/v5.12.2 | [email protected] | github.com | |
| github.com/Jovancoding/Network-AI/security/advisories/GHSA-mxjx-28vx-xjjj | 134c704f-9b21-4f2e-91b3-4a467353bcc0 | github.com | |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.