Argo CD MCP: unauthenticated cluster access
An investigation into the authentication boundary between an AI tool and the infrastructure it controls.
Open the original ↗
Security research · CVE-2026-82456
Where does an unauthenticated request stop?
A small, visual comparison of the Argo CD MCP server boundary: in the affected release, reachable HTTP transport could lead into configured credentials and deployment tools.
Unauthenticated traffic can cross the server boundary.
- 01CallerNo inbound credential
- 02MCP serverHTTP transport
- 03Argo CDConfigured token
- 04KubernetesDeployment tools
Ready to trace the request path.
Simplified illustration · no network requests
What changed in 0.9.0? The fixed release adds token authentication and binds the server to localhost by default.
This is an authentication-boundary comparison, not a claim that token checks alone solve every deployment risk.
The authentication boundary
The affected Argo CD MCP server accepted unauthenticated HTTP requests and reused its configured Argo CD credential. A caller able to reach that transport could invoke deployment operations through the server.
The published Apiiro investigation documents the affected configuration, reproduction, disclosure timeline, and remediation. It also covers a separate prompt-injection path through an agent with access to the tools.
The network demonstration required a reachable HTTP transport and a configured Argo CD credential. The maintainer advisory is GHSA-rp45-5x3v-48mr; the full article explains these prerequisites and the fix.