Argo CD + Cursor: Both Ends of Your Pipeline Have Unpatched Critical Vulns
Two 9.8-severity bugs, same root cause: a privileged component trusting its inputs
The deployment pipeline and the IDE are both exposed. Different vulnerability classes. Same architectural mistake, and the same afternoon of work to close them.
Argo CD: Unauthenticated RCE from Any Cluster Pod
Synacktiv found this via CodeQL static analysis. Argo CD's repo-server gRPC endpoint answers requests from any pod in the cluster, with no authentication. Here is what the attack chain actually does: craft a malicious Kustomize configuration → pass arbitrary flags to the kustomize binary → get command execution in the repo-server container → pivot to Redis → read stored Git credentials → push manifests that Argo CD applies with elevated cluster privileges.
There is no patch. Your only mitigation is a NetworkPolicy restricting ingress to repo-server exclusively from argocd-server and application-controller pods.
The reason this matters: repo-server holds Git credentials, often with write access to infrastructure repos, plus deployment secrets and Kubernetes API tokens. Compromise any workload in the cluster, say a CI job with an exposed debug port, and this path leads to full cluster ownership.
Cursor IDE: Zero-Click Sandbox Escape
CVE-2026-50548 and CVE-2026-50549 hit every Cursor version before 3.0. No user interaction. Content the agent reads can escape the sandbox, write arbitrary files, and execute code. That content includes repository files, documentation, web search results, and MCP server responses.
The bug is generic to agentic IDEs that both read untrusted input and hold write access to the filesystem. Any tool with that read/write combination inherits the same exposure. Cursor is the one with published CVEs and a patch.
The Pattern
Both bugs come from a privileged component that trusts its inputs. Argo CD's repo-server assumes only authorized components speak gRPC to it. Cursor assumes read content contains no escape sequences. Neither assumption holds.
Immediate Actions
- The Cursor fix is an update to 3.0+, pushed through fleet management. That closes both CVEs.
- The Argo CD fix is not a fix. It is a NetworkPolicy scoping repo-server ingress to argocd-server and application-controller. Nothing else reaches the listener.
- Any agentic tool in the stack that reads untrusted sources and holds filesystem or execution privileges inherits this exposure, patched or not. Each one needs a threat model review this sprint.
What to do
Force-update all Cursor installations to version 3.0+ via fleet management
Deploy Kubernetes NetworkPolicies restricting Argo CD repo-server ingress to only argocd-server and application-controller pods
Enumerate all agentic tools with both read-from-untrusted and write-to-filesystem capabilities — create threat model documents
If running Langflow or LLM orchestration tools: verify they are not internet-exposed, enforce auth on all endpoints