argocd-mcp CVE-2026-82456: a CVSS 10 MCP server

A perfect 10.0 is rare, and this one is not exotic. CVE-2026-82456 in argocd-mcp — the Model Context Protocol server that lets an AI agent drive Argo CD — binds its HTTP transport to 0.0.0.0 and accepts MCP sessions without asking the caller for credentials. Anyone who can reach the port inherits the operator's Argo CD token. No exploit chain, no memory corruption, no clever primitive. The server just answers. It was published August 29, and the fix is version 0.9.0.

What actually happened

The GitHub Security Advisory names three defects that stack into one:

1. The HTTP server listens on all interfaces, not localhost.
2. When ARGOCD_API_TOKEN is set in the environment, that credential is used on behalf of unauthenticated callers.
3. There is no Host or Origin validation, so a browser on the same network is a viable client too.

The classification is CWE-1327, Binding to an Unrestricted IP Address. The CVE record scores it 10.0 under both CVSS 3.1 and 4.0 — the 3.1 vector carries S:C, scope changed, because the damage lands somewhere other than the vulnerable component. That somewhere is your cluster.

What an attacker does with a session is the whole tool surface: create Argo CD applications, point them at a repository they control, and trigger a sync. Argo CD is a GitOps controller. Its job is to take a manifest and make the cluster match it. So "create an application and sync it" is a complete path from an open port to attacker-authored workloads running in production, with no user interaction anywhere in the sequence.

Affected: argocd-mcp 0.8.0 and earlier. Fixed: 0.9.0. If you can't upgrade today: firewall the listener, keep it on a trusted network only, or set MCP_READ_ONLY=true to strip the write tools. Read-only is a tourniquet, not a fix — an unauthenticated stranger can still enumerate every application you run.

Why an MCP flaw matters for your business

Skip the Argo CD specifics for a second. The pattern is what should worry you.

MCP servers get installed the way dev tooling has always been installed — someone wanted their agent to reach a system, found a server, ran it, and it worked. It worked, so nobody read the transport config. The default was 0.0.0.0 because the author was thinking about containers, and the token went in an environment variable because that is what environment variables are for. Every one of those decisions is defensible alone. Together they publish your deploy pipeline.

An MCP server is a credential proxy with a tool menu. Its entire purpose is to hold a privileged token and expose the actions that token permits. That makes the listener's bind address a production security control, and almost nobody treats it as one. If you are running MCP servers for your CI, your database, your ticketing system, or your cloud console, each is a small unauthenticated API in front of a credential you would never paste into Slack.

Three things worth doing this week, in order:

Inventory what is running. Every MCP server, every host, every user's laptop included. ss -lntp or netstat -ano and look at the local address column. 0.0.0.0 or [::] means the whole network, not "my machine."

Check the token behind each one. The blast radius of an MCP flaw is exactly the permission set of the credential it holds. An Argo CD token scoped to one project is a bad afternoon. An admin token is an incident. Scope them down now, while it is a maintenance task instead of a forensics exercise.

Decide who watches these advisories. MCP servers are young, mostly community-maintained, and moving fast. They do not appear in your OS patch cadence and most do not appear in your dependency scanner either. Somebody by name should be subscribed to the release feeds for the ones you run.

Sources: GitHub Security Advisory GHSA-rp45-5x3v-48mr, CVE-2026-82456.