Critical flaw in Argo CD's AI helper let anyone with network access hijack deployments
A maximum-severity bug in the argocd-mcp server skipped login checks entirely - but only if you'd switched it on and pointed it at the open network in the first place.
A newly disclosed vulnerability in a tool used to let AI assistants control Argo CD deployments has been rated the maximum possible severity - CVSS 10.0. The catch is that it only bites people who ran the software in a specific, fairly careless configuration, and there’s already a fix available.
What the bug actually does
The affected project is argocd-mcp, an implementation of the Model Context Protocol that lets AI tools like Copilot chat with Argo CD, the popular continuous-deployment platform used to push code changes live on Kubernetes clusters. Version 0.8.0 of the server has two problems that combine badly, according to the GitHub security advisory: it listens on every network interface by default, rather than just the local machine, and when it’s been set up with an ARGOCD_API_TOKEN, it will start a session for any caller without asking for so much as a password.
The advisory’s author says they reproduced the issue manually against the published package and a local test target, not a live Argo CD cluster - so this is a confirmed proof of concept, not an observed real-world attack. In plain terms: anyone who can reach the server over the network could ask it to do things using the stored Argo CD credentials, including telling Argo CD to sync a brand-new “Application” pointing at a repository the attacker controls. Argo CD would then dutifully deploy whatever the attacker put there, using the legitimate stored token to do it.
So who is actually at risk
This is not a bug that threatens every Argo CD user, or even every user of this MCP server. Three things have to be true simultaneously for it to matter: you’re running argocd-mcp 0.8.0, you’ve configured it with an API token so it can act on Argo CD’s behalf, and the server’s network port is reachable by someone other than you - whether that’s a colleague on the same office network, another workload on a shared cloud VPC, or, worst case, the open internet.
If you’re only using the MCP server locally over stdio, with no HTTP token configured, or you’ve kept it firmly behind a firewall reachable by nobody untrusted, this specific flaw has nothing to bite. The project itself is a fairly niche developer tool - GitHub shows a modest 563 stars - so this is squarely an issue for teams experimenting with AI-driven DevOps tooling, not something that touches ordinary software users or Argo CD deployments that don’t use the MCP add-on at all.
What to do about it
The fix is already out: version 0.9.0 patches the flaw, according to the advisory, and anyone running the affected 0.8.0 release should upgrade without delay. In the meantime, or as a belt-and-braces measure afterwards, restrict which network addresses can reach the MCP server’s HTTP transport, and treat any Argo CD API token handed to an AI tool as sensitive as the credentials themselves - because, as this bug shows, that’s effectively what it becomes.
The takeaway
This is a real, serious flaw with a real fix, not a theoretical worst case - full marks to the maintainers for a fast patch and a candid writeup. But its blast radius is bounded: it needs a specific setup exposed to a network of untrusted people to actually go wrong. If that’s not your situation, there’s no need to panic; just make sure you’re not still running 0.8.0 with an open door behind it.