The Argo CD Token Was Outbound. The MCP Server Treated Every Caller as Trusted.
An official Argo Project Labs MCP server exposed its full Argo CD tool surface to any network caller, then executed those tools with the operator’s stored Argo CD API token. No inbound credential was required.
The core mistake in argocd-mcp 0.8.0 was simple and consequential: an outbound credential was treated as though it established trust in an inbound caller. If the service could reach Argo CD, every caller who could reach the MCP listener could potentially act with the same token.
The issue is now tracked as CVE-2026-82456 with a CVSS 10.0 score. The public advisory includes a self-contained reproduction against the published npm package. There is no confirmed evidence of malicious exploitation at the time of writing.
The Argo CD token authenticated the wrong side
Operators could configure ARGOCD_API_TOKEN so that argocd-mcp could call the Argo CD API. That token authenticates the MCP server to Argo CD. It says nothing about the identity or authority of the client connecting to the MCP server.
Version 0.8.0 did not maintain that distinction. Its HTTP transport accepted requests without a caller token, fell back to the environment’s Argo CD token and forwarded that bearer credential to the downstream API. The listener also bound to every interface and did not validate the request’s Origin or Host.
| Condition | Version 0.8.0 behaviour | Security consequence |
|---|---|---|
| Network binding | The HTTP and SSE listeners bound to all interfaces. | Hosts on a reachable network path could connect, even when the operator expected a local development service. |
| Inbound authentication | No separate MCP caller credential was required. | Any reachable caller could initialise a session and invoke tools. |
| Outbound token | The server used ARGOCD_API_TOKEN when the request supplied no token. | The caller inherited the Argo CD permissions of the stored service credential. |
| Browser-origin checks | Origin and Host were not validated. | A malicious webpage could potentially reach a local listener through DNS rebinding. |
| Write capability | Write tools were enabled unless MCP_READ_ONLY=true. | A caller could create, update, delete, prune or sync applications when the stored Argo CD token allowed it. |
From an MCP request to a Kubernetes deployment
The advisory’s reproduction used a harmless local API sink rather than a real Argo CD cluster. It started argocd-mcp 0.8.0 with a placeholder outbound token, connected over the machine’s LAN address without presenting a credential, created an Argo CD Application that referenced an attacker-controlled repository and requested a sync.
Both tool calls succeeded. The local sink recorded the stored bearer token on the requests to create and sync the Application. This independently demonstrated the trust-boundary failure while avoiding deployment of hostile manifests to Kubernetes.
The practical impact depends on two downstream controls: the permissions attached to the Argo CD token and the restrictions of the selected AppProject. Argo CD’s automatically created default project is deliberately permissive. Unless an operator has hardened it, the project allows any source repository, any destination cluster and namespace, and all resource kinds.
A write-capable token can therefore turn an unauthenticated MCP request into a GitOps deployment path. The exposed tools also support application update, deletion, pruning and resource actions. Even read-only access may disclose applications, registered clusters, managed resources, logs and events.
Version 0.9.0 rebuilds the boundary
The project released argocd-mcp 0.9.0 on 11 August 2026 at 15:32:50 UTC. The security advisory followed at 15:47:14 UTC. The patched release changes the network defaults and separates inbound authentication from the downstream Argo CD credential.
- Loopback by default: HTTP and SSE listeners now bind to
127.0.0.1instead of every interface. - Separate inbound token:
MCP_AUTH_TOKENrequires callers to send a bearer credential on every request. - Fail closed on wider exposure: a non-loopback bind requires either
MCP_AUTH_TOKENor an explicit--allow-unauthenticatedacknowledgement for deployments protected by an external proxy, mesh or policy. - Origin protection: browser Origin is checked, including scheme, host and port, to stop malicious pages and DNS-rebinding routes.
- Host validation: loopback names are allowed by default, with explicit additional Host values available for other deployment patterns.
- Startup validation: unusable or unsafe configurations fail at startup instead of being silently accepted.
The affected range is unusually narrow: the advisory lists only argocd-mcp 0.8.0 as vulnerable and 0.9.0 as patched. Operators using http or sse transport should upgrade. The stdio transport does not open the vulnerable network listener.
Why this matters beyond one MCP server
MCP servers sit between a caller and an authority-bearing API. Their security model must therefore answer two separate questions: who may call the MCP server, and what may the MCP server do downstream?
A secret used for the second question cannot answer the first. The same separation applies to cloud credentials, CI tokens, database passwords and Kubernetes service-account tokens. When an MCP server has a powerful outbound credential but no inbound authentication, the protocol bridge becomes an authority amplifier.
The package is not obscure in registry terms. npm’s official download API recorded 18,149 downloads for argocd-mcp from 23 through 29 August 2026. Download counts do not prove active deployments, but they strengthen the case for rapid inventory and version checks.
What defenders should do now
- Find version 0.8.0. Check npm lockfiles,
npxinvocations, container images, Helm values, Compose files and Kubernetes manifests. - Upgrade to 0.9.0 or later. Redeploy workloads that track a mutable
latestimage so the running container actually changes. Pin 0.9.0 or a later verified release. - Review network exposure. Confirm whether port 3000 was published, whether a Service exposed the Pod, and which network segments could reach the listener.
- Rotate exposed Argo CD tokens. If version 0.8.0 was reachable by untrusted clients, treat the downstream token as potentially used, not merely disclosed.
- Inspect Argo CD audit history. Review Application creation, source-repository changes, syncs, pruning, deletion and resource actions performed during the exposure window.
- Separate credentials deliberately. Use
MCP_AUTH_TOKENfor callers andARGOCD_API_TOKENonly for downstream Argo CD access. Do not reuse either token elsewhere. - Reduce downstream authority. Use a least-privilege Argo CD token, dedicated AppProjects, approved source repositories, limited destinations and restricted resource kinds. Harden the
defaultproject. - Use read-only mode where possible.
MCP_READ_ONLY=trueremoves five modification tools, but it does not replace authentication because read tools still expose operational data.
CVE.org published CVE-2026-82456 on 29 August 2026 at 13:47:57 UTC, more than two weeks after the original project advisory and patch. That delay explains why a high-impact MCP security release could be missed by monitoring focused primarily on newly assigned CVE identifiers.
Sources and further reading
- Argo Project Labs security advisory, published 11 August 2026 at 15:47:14 UTC; updated one second later.
- argocd-mcp 0.9.0 release notes, published 11 August 2026 at 15:32:50 UTC; updated 11 August 2026 at 17:10:58 UTC.
- argocd-mcp 0.9.0 network-exposure documentation.
- Argo CD documentation: The Default Project.
- Official CVE record, published and updated 29 August 2026 at 13:47:57 UTC.
- NVD vulnerability record.
- npm download API, 18,149 downloads from 23 through 29 August 2026.
