CVE-2026-82456: Argo CD MCP Server Kubernetes Takeover

Summary

Apiiro reports CVE-2026-82456, a Critical vulnerability in the argocd-mcp 0.8.0 MCP server, with a stated CVSS 3.1 score of 10.0. In the affected HTTP configuration, an unauthenticated network caller can invoke Argo CD tools using the server's configured credential. The reported exposure combines an all-interface listener, missing Host and Origin checks, and credential fallback that treats possession of an outbound Argo CD token as sufficient to serve an inbound request.^[0]

The research demonstrates an authentication-boundary failure rather than a confirmed Kubernetes compromise. From a second machine, the researchers invoked create_application and sync_application without credentials; a local sink recorded upstream requests bearing a placeholder Argo CD token. Apiiro explicitly states that no real Argo CD instance or Kubernetes cluster was contacted. Deployment impact therefore remains a source-described consequence contingent on the real token's permissions and applicable Argo CD project restrictions.^[0]

The affected scope described in the article is argocd-mcp 0.8.0 using HTTP, with ARGOCD_API_TOKEN or a token registry configured, and a listener reachable from another host, container, or pod. The stdio transport does not open a network listener and is described as unaffected. Apiiro also identifies prompt injection through a connected agent as an alternative route to tool abuse, without presenting it as observed exploitation.^[0]

According to the article, version 0.9.0 was released on August 11, 2026, with localhost binding, separate inbound authentication, exposure safeguards, and header validation. Defenders should upgrade, rotate the Argo CD credential if the listener was accessible to untrusted parties, and inspect application sources, synchronization history, and operations attributed to the server's account. The supplied substantive evidence is a single research article; linked advisories and release notes were not supplied as independent source bodies.^[0]

Attack chain

1. Research reproduction: unauthenticated session establishment: Apiiro ran argocd-mcp 0.8.0 with a placeholder Argo CD token and an upstream local logging sink. A second machine on the same LAN supplied no credentials and successfully initialized an MCP session despite an arbitrary Origin header. This was a controlled reproduction, not an observed intrusion.^[0]
2. Research reproduction: tool discovery and read access: The unauthenticated session successfully listed 15 tools and invoked list_applications. The exposed surface comprised ten read-only tools and five tools capable of changing state.^[0]
3. Research reproduction: application creation: The researchers invoked create_application with an application specification pointing to a demonstration attacker-controlled repository and targeting a production namespace. The sink recorded an application-creation request authenticated with the configured placeholder token.^[0]
4. Research reproduction: synchronization request: The researchers then invoked sync_application with pruning enabled. Both write calls returned successful tool responses, and the sink recorded an authenticated synchronization request. The experiment established request forwarding under the server's identity; it did not demonstrate actual workload execution on a cluster.^[0]

Disclosure timeline

How it works

Network exposure begins with app.listen(port) without an explicit host argument, which the article identifies as binding Node.js to every interface. The published container defaults to HTTP transport and exposes port 3000, making this configuration particularly relevant to container deployments.^[0]

The central authentication flaw is in per-session credential resolution. The server first reads x-argocd-api-token and otherwise falls back to ARGOCD_API_TOKEN. It rejects the request only when no resolved token exists and the token registry is empty. Consequently, an operator following the documented credential configuration can enable anonymous callers to use the server's outbound authority. The demonstrated behavior is authenticated request forwarding, not disclosure of the token to the caller.^[0]

The server's custom Express application performs neither Host nor Origin validation. Apiiro reports that arbitrary-Origin requests were accepted even though its MCP SDK dependency already included hostHeaderValidation() and createMcpExpressApp(). The missing checks form a separate browser and DNS-rebinding exposure addressed by the reported fix; the demonstrated LAN attack itself required neither a browser nor user interaction.^[0]

The five write tools are create_application, update_application, delete_application, sync_application, and run_resource_action. Creation followed by synchronization can cause Argo CD to deploy manifests from a caller-selected repository when the token and AppProject permit it. Apiiro describes the default AppProject as allowing any source repository, destination cluster, and resource kind; this supports the article's takeover scenario but does not establish that every deployment has equivalent permissions.^[0]

Read tools expose application inventory, repository locations, cluster information, managed resources, logs, and events. The article also describes how an agent processing attacker-controlled issues, pull requests, logs, or web content could be induced to invoke the same tools through prompt injection without direct network exposure. MCP_READ_ONLY=true removes the five write tools but leaves the read surface available.^[0]

Apiiro attributes the CVSS scope change to the MCP server causing a separate security authority—Argo CD and its managed clusters—to act on the caller's behalf. The reported 10.0 score therefore reflects potential cross-boundary write impact, while the supplied experimental evidence stops at successful forwarding to a sink.^[0]

The reported 0.9.0 changes separate inbound and outbound trust: MCP_AUTH_TOKEN authenticates incoming requests, while ARGOCD_API_TOKEN is documented as outbound only. The release also defaults to loopback binding, refuses a non-loopback bind without inbound authentication unless explicitly overridden, validates Origin and Host under the documented conditions, and places security middleware before JSON parsing.^[0]

Affected versions and patch status

Key takeaways

• The decisive flaw is trust-boundary confusion: a credential authorizing the server to call Argo CD also enabled service to callers who had not authenticated.^[0]
• The two-call demonstration establishes anonymous access to privileged upstream requests, not a verified production takeover. No real Argo CD instance or Kubernetes cluster was contacted, and the supplied article does not report in-the-wild exploitation.^[0]
• Practical impact depends on both reachable transport and downstream authority. HTTP exposure opens the demonstrated network path; token permissions and AppProject policy determine what the resulting Argo CD requests can accomplish.^[0]
• Restricting network exposure does not address the article's separate agent-mediated prompt-injection scenario. Removing unnecessary write tools limits that scenario, but read-only operation still permits access to the server's read-tool data.^[0]
• All substantive findings in this dossier are single-source. The supplied material contains no independently retrieved advisory body, real-world attacker attribution, or actionable malicious infrastructure; demonstration artifacts are not compromise indicators.^[0]

Defensive actions

• Upgrade affected argocd-mcp deployments to version 0.9.0 or later.: The reported fix addresses the combined exposure through safer listener defaults, distinct inbound authentication, startup safeguards, and Origin and Host validation.^[0]
• Rotate the Argo CD API token used by the server if the HTTP listener was reachable from anything not fully trusted.: The vulnerable credential fallback allowed untrusted callers to exercise that account's authority. Rotation is explicitly recommended for exposed deployments.^[0]
• Inventory Argo CD applications and review unfamiliar source repositories, destinations, and synchronization history during the exposure period.: The demonstrated create-and-sync sequence uses a caller-selected repository to request deployment. The article recommends examining repoURL values and provides an application-inventory command covering project, source, and destination namespace.^[0]
• Review Argo CD operations attributed to the account behind the MCP server's token and compare their timing with legitimate agent use.: The article states that application creation, updates, synchronization, and deletion generate Kubernetes events attributed to the acting account. Abused requests would therefore appear under the server's configured identity.^[0]
• Determine whether port 3000 was reachable from other hosts, nodes, or namespaces, and examine connections from addresses other than the intended agent.: HTTP exposure is a required condition for the demonstrated unauthenticated network path, and the vulnerable container defaults make port 3000 a specific review target.^[0]
• Set MCP_READ_ONLY=true unless the connected agent requires state-changing operations.: This removes all five write tools, limiting both network-driven and agent-mediated abuse. It does not eliminate exposure of information available through read tools.^[0]
• Keep the patched listener on localhost where possible; for remote access, configure MCP_AUTH_TOKEN or an authenticating proxy.: Version 0.9.0 defaults to loopback and separates inbound authentication from the outbound Argo CD credential. The article specifically recommends authenticated remote access rather than treating ARGOCD_API_TOKEN as caller authentication.^[0]