# Network-AI ApprovalInbox Unauthenticated Cross-Origin Approval Bypass (GHSA-mxjx-28vx-xjjj)

- **Severity:** High
- **Signature ID:** `6d644e3a-1460-4224-b385-dbe8fa38db4c`
- **MITRE ATLAS:** AML.T0049 (Exploit Public-Facing Application)
- **OWASP:** ASI03 (Identity and Impersonation), ASI06 (Goal and Instruction Manipulation), LLM06 (Excessive Agency)

## Summary

network-ai's ApprovalInbox component is meant to require a human to approve risky agent actions like shell commands or spending money. It has no login check at all and allows any website to talk to it, so anyone who can reach the port can approve or deny pending actions without permission.

## How the attack works

The ApprovalInbox HTTP server exposes endpoints to list pending approvals and to approve or deny them. These endpoints check no authentication token or session, and every route sends a wildcard CORS header (Access-Control-Allow-Origin: *). An attacker can be a process on the same machine, an SSRF target reachable from another service, a remote client hitting a non-local address, or simply a malicious webpage the operator's browser visits. That attacker lists pending approvals with a GET request, then sends a POST to approve or deny a specific item, and the gated action — such as a shell command or a budget spend — proceeds as if a human had signed off.

## Why it matters

An organization loses the safety control meant to keep humans in the loop before an AI agent runs shell commands, writes data, or spends money — an outside party can rubber-stamp those actions remotely with no credentials at all.

## What you can do

- Put ApprovalInbox behind an authentication layer (reverse proxy with auth, mutual TLS, or a required token) rather than relying on network position alone.
- Restrict the ApprovalInbox port to localhost or a trusted internal network; do not expose it to the internet or shared hosts.
- Replace the wildcard CORS header with an explicit allow-list of trusted origins, or disable CORS entirely for this control-plane API.
- Review approval logs for any approve/deny requests lacking an authenticated operator session, and treat unexplained approvals as compromise indicators.

## Known benign look-alikes

- Legitimate operator approving a pending action through an authenticated ApprovalInbox deployment that has been hardened with a reverse-proxy auth layer — expected to match; review confirms intent.
- Security advisory or PR text quoting the GHSA-mxjx-28vx-xjjj PoC.
- A read-only status check against an endpoint that is not the approvals control plane.

## References

- https://agentthreatrule.org/en/rules/ATR-2026-01981
- https://github.com/advisories/GHSA-mxjx-28vx-xjjj

---
Source: https://www.netzilo.com/threats/atr-network-ai-approvalinbox-unauthenticated-cross-origin-approv