Argo CD Security Landscape 2026: Four Critical Flaws, Three Without CVEs – The Repo Server as an Attack Vector

Argo CD is the de facto standard for GitOps on Kubernetes: In the 2023 Argo community survey, 93 percent of respondents said they use the tool in production. And right there, at the center of the deployment pipeline, the security situation escalated in October 2026. On October 7, the project released six security advisories in one go — four of them with the highest rating CVSS 9.9 (critical). Three of the four critical vulnerabilities still have no CVE number today. For teams whose patch processes rely on CVE feeds and scanners, this is a structural blind spot. Added to this is a vulnerability in the Repo Server, known since July 2026 and still unpatched, that allows unauthenticated attackers to execute code. Time for a sober look at the attack surface of the most important GitOps controller.

Six advisories, four critical — and hardly any CVE visibility

All six advisories published on October 7, 2026 are fixed in the same four releases: v3.3.15, v3.4.10, v3.5.4 and v3.6.0-rc2. Four of them carry a CVSS rating of 9.9. But only one vulnerability has made it into the NVD so far: CVE-2026-55797, rated 8.8 by GitHub. A second, CVE-2026-77459, has a CVE ID but no NVD entry yet. Three of the four CVSS 9.9 findings have no CVE number at all, and five of the six GHSA records return a 404 in OSV. Anyone who bases their upgrade prioritization solely on CVE feeds sees only a fraction of this wave.

The Repo Server: bottleneck of the GitOps pipeline

Four of the six bugs converge on one component: the argocd-repo-server, the pod that translates Git content into Kubernetes manifests. It holds the Git, Helm, and OCI credentials of all repositories in the installation. Three different attack paths start with content in a repository: a Jsonnet file read path (traceable back to v0.9.0, 2018), a Kustomize remote ref via git fetch --upload-pack (since v2.7.0), and a Helm plugin execution via configHome with --enable-helm.

None of these vulnerabilities require more than the ability to commit content to a repository from which an Application syncs — in the GitOps model, a routine permission for app teams, CI jobs, and increasingly automated agents. The confused deputy effect is the real problem: a developer who is only allowed to change their own namespace ends up in a process that holds the credentials of all tenants — exactly the S:C (Scope Change) appears in all four CVSS vectors.

CVE-2026-55797: Command injection via SSH proxy

The only vulnerability with an NVD entry is a command injection (GHSA-j6cw-g6p4-7hch, CWE-78): For SSH Git repositories with a proxy URL, the proxy host and port are copied unchecked into an SSH ProxyCommand. A hostname with shell metacharacters breaks out of the command and executes arbitrary code in the Repo Server. All versions from v2.11.0 are affected; the behavior was introduced in January 2024 with SOCKS5 proxy support. The vulnerability can be triggered by anyone who can create a repository or a credential template — including project-wide repository permissions or argocd repo add --proxy. The fix validates proxy URLs via an allowlist: SSH proxies only socks5/socks5h, non-empty host, port 1–65535, hostnames exclusively alphanumeric with dots and hyphens.

The AppProject bypass: Multi-tenant GitOps wobbles

For multi-tenant operations, CVE-2026-77459 (GHSA-fmxq-cgp8-87wp, CVSS 9.9, CWE-863) is the most interesting vulnerability: Argo CD normally checks whether an Application matches its AppProject before creating resources — but the PreDelete and PostDelete hooks skip this check entirely and are executed with the Application Controller's credentials on the target cluster. "In a typical installation, this access is broad, so a tenant can create a cluster-wide object like a ClusterRoleBinding," the advisory states. The PostDelete path has "never applied" the project check since v2.10.0.

Unpatched since July: the "Octopus Trap"

Since July 1, 2026, another Repo Server vulnerability has been public for which there is still neither a fix nor a CVE. Synacktiv demonstrated an unauthenticated remote code execution: The Repo Server's internal gRPC service does not check callers; a crafted request to GenerateManifest can redirect the Kustomize options --enable-helm and --helm-command to a script from an attacker's repository. Anyone who reaches the port gets a shell. The researchers reported the vulnerability in January 2025 — about 18 months later it was still unpatched. The escalation continues: With code execution, an attacker reads the Redis password from the environment, poisons the manifest cache, and causes the Application Controller to roll out their own workload on the next sync — a repeat of CVE-2024-31989. Argo CD ships with NetworkPolicies, but the official Helm chart leaves them disabled by default (networkPolicy.create: false). Helm-based installations are therefore often unprotected.

Support cutoff as a risk

All October advisories carry the same sentence: "Argo CD 2.x and 3.0 to 3.2 are out of support and will not receive a patch." The affected code paths sometimes date back to v0.9.0 (2018). Anyone still running 2.x is operating known, published 9.9 RCEs with no prospect of a fix — only an upgrade to 3.3 or newer helps.

What teams should do now

Upgrade: Deploy v3.3.15, v3.4.10 or v3.5.4 — 2.x and 3.0–3.2 will not receive patches. Use the signed release assets (Cosign, SLSA Level 3).
Network isolation: Enable NetworkPolicies. kubectl get networkpolicy -A should show a policy per component; make Repo Server and Redis accessible only to Argo CD's own components.
RBAC: Do not grant repository create/update to untrusted users — not even project-wide.
Monitoring: Watch the Repo Server for unexpected shells and Git clones, Redis for accesses from unexpected sources, and syncs without a matching commit in the repository.
Processes: Do not treat CVE feeds as the sole truth — three of the four critical October vulnerabilities are invisible there. Regularly read the release notes of the projects you use.

Conclusion

The October wave shows two things: The Repo Server has become the crown jewel of the GitOps attack chain, and the severity of a vulnerability and its visibility in scanner feeds are independent variables. GitOps teams should treat Argo CD like tier-zero infrastructure: network policies as standard, least privilege instead of blanket repository write permissions, and monitoring that does not wait for CVE numbers. Those who apply the four patches and close their network boundaries have the wave behind them — those who rely only on scanners may not.