argocd-mcp: HTTP transport binds to all interfaces and serves MCP sessions with no caller authentication

Impact

When ARGOCD_API_TOKEN is set, argocd-mcp 0.8.0 accepts MCP sessions from anyone who can open a TCP connection to it and executes the full tool surface using the operator's stored Argo CD token. That means creating Applications, triggering syncs, and mutating Argo CD resources with whatever privileges the token carries - typically cluster-wide, since GitOps controllers are the thing that installs everything else. On a GPU fleet this is the shortest path from network reach to workload placement: Argo CD usually owns the manifests for the GPU Operator, device plugin, driver DaemonSet and node feature discovery, all of which run privileged and on every accelerator node. An attacker who can sync an Application of their choosing can land a privileged pod on GPU nodes across the cluster, and cleaning that up means re-reconciling the fleet rather than restarting one service. Because it binds every interface rather than loopback, a listener intended for a single operator's IDE is reachable from the pod network or the host's LAN.

Who can reach it

Anyone with network reach to the argocd-mcp listener. No authentication is required and no credential of the attacker's own is needed - the server uses the operator's configured ARGOCD_API_TOKEN. Since the transport binds all interfaces, that includes any workload on the same pod or host network, not just localhost.

What to do

Treat any argocd-mcp 0.8.0 listener as an unauthenticated Argo CD admin endpoint. Stop or upgrade the process per the maintainer advisory (GHSA-rp45-5x3v-48mr); the record does not name a fixed version, so check that advisory before pinning one. Until then, bind the transport to loopback only, or firewall the port so only the intended operator host can reach it, and restart the process for the change to take effect. If the listener was exposed, rotate the Argo CD API token it held and audit Argo CD for Applications and syncs you did not initiate.

References

Related entries

• Rancher: Cluster owners, members and even base users retrieve plaintext credentials via the Kubernetes APICVE-2021-36782 · RancherCritical
• Rancher: Insufficiently protected credentials let project members read passwords and API tokensCVE-2021-36783 · RancherCritical
• Argo CD: Improper access control allows a low-privileged user to escalate to Argo CD adminCVE-2022-24768 · Argo CDCritical
• Rancher: Cleartext credential storage lets managed-cluster users read credentialsCVE-2022-43757 · RancherCritical
• Rancher: Standard users manipulate Kubernetes secrets in the local (management) clusterCVE-2023-22647 · RancherCritical
• Rancher: Update-logic failure misconfigures Rancher's admission webhook, disabling the validation that enforcesCVE-2023-22651 · RancherCritical