argocd-mcp Unauthenticated HTTP Exposure (CVE-2026-82456): Scope and Response

argocd-mcp connects Model Context Protocol clients to Argo CD operations. CVE-2026-82456 arises where two different trust questions—who called the MCP server and which credential the server uses outbound to Argo CD—were not kept separate. The project advisory says version 0.8.0 can bind its HTTP transport to every network interface and, when ARGOCD_API_TOKEN is configured, create an MCP session without a caller presenting an inbound credential. Tool requests are then executed with the operator's stored Argo CD token.

This is therefore more than an exposed management port. A reachable listener can bridge an unauthenticated request into Argo CD API calls and, depending on the stored token and project policy, into Kubernetes resource changes. The official advisory marks 0.8.0 as affected and 0.9.0 as patched, with a Critical CVSS 3.1 score of 10.0. The response must treat the listener scope, caller authentication, and Argo CD token privileges as one trust boundary.

The Exposure Path

The starting condition is an argocd-mcp 0.8.0 process using HTTP or SSE transport on a network-reachable path. The advisory explains that the listener starts without a host argument and therefore binds every interface, while the custom Express application lacks Host validation. If ARGOCD_API_TOKEN or a token registry path is also configured, the stored value—intended for outbound requests to Argo CD—can effectively stand in for caller authentication. Public internet exposure is not required; a shared development network, VPN segment, Kubernetes NodePort, or another reachable workload can satisfy the condition.

Privilege Expansion Through the Stored Token

The exposed tool surface includes read operations for applications, clusters, resources, logs, and events. Unless MCP_READ_ONLY is enabled, it can also include application creation, updates, deletion, sync, pruning, and resource actions. A caller does not need to know the token value because the MCP server forwards authorized requests on the caller's behalf. Actual impact is bounded by the stored token and Argo CD project policy, so review the transport mode, reachable path, token source, read-only setting, service account, and project source and destination restrictions together.

Patched Version and Defensive Boundary

Upgrade to argocd-mcp 0.9.0 or later, then verify the version running in every process or container rather than relying on a deployment manifest alone. Confirm that cached 0.8.0 images, stale pods, and rollback definitions cannot restore the affected build. For local-only use, bind to 127.0.0.1. For remote use, place the service behind a management network or authenticated proxy, apply explicit Host and Origin controls, and keep inbound caller authentication separate from ARGOCD_API_TOKEN.

Administrator Checklist

1. Find every running argocd-mcp instance and confirm whether version 0.8.0 is present.
2. Record bind addresses, published ports, Kubernetes Services and Ingresses, proxies, and firewall paths.
3. Upgrade to 0.9.0 or later and confirm every replica and node runs the new build.
4. Separate inbound caller authentication from the stored Argo CD token and enforce Host and Origin rules.
5. Enable read-only mode where possible and scope the token and Argo CD project to the minimum required resources.

If the listener was previously reachable, correlate Argo CD audit records, MCP access logs, and application creation, update, sync, and pruning events across the same time window. Rotate a token through a controlled process when indicated, recording deployment of the new value and revocation of the old one. Completion means that unauthorized network locations cannot reach the listener, approved paths require caller credentials, and write operations stay inside the intended project and account boundaries.

Post-Upgrade Validation

Test the restored trust boundary rather than only the package installation. From an unapproved network, the listener should be unreachable. From an approved path, a session should not be created without the required inbound credential. Host and Origin policies should reject unexpected values, while legitimate MCP clients continue to perform the authorized read operations. Treat the MCP service as a privileged workload that brokers cloud-management authority, and inventory its version, transport, listener, front-end authentication, token owner, token privileges, and linked Argo CD project.