Argo CD repo server hit by four critical flaws, three without CVE numbers

A wave of critical fixes, mostly invisible to CVE feeds

On October 7, 2026, the Argo CD project published six security advisories in a single batch, four of them rated critical at CVSS 9.9. According to a security analysis on dev.to, the patches are available in releases v3.3.15, v3.4.10, v3.5.4 and v3.6.0-rc2. The awkward part for anyone triaging upgrades from CVE feeds: at the time of writing only one flaw has an NVD entry (CVE-2026-55797, scored 8.8 by GitHub), a second has a CVE identifier but no NVD record (CVE-2026-77459), and three of the four 9.9-rated bugs have no CVE at all. The dev.to author also reports that five of the six GitHub advisories return a 404 in the OSV database, so scanner-driven pipelines would catch only a fraction of this release.

The repo server is the common target

Four of the six bugs land on argocd-repo-server, the component that converts Git content into Kubernetes manifests and therefore stores the Git, Helm and OCI credentials of every repository in the installation. The dev.to analysis maps three attack paths that require nothing more than commit access to a repository an Application syncs from — an ordinary permission for app teams, CI jobs and increasingly autonomous agents: a Jsonnet file-read issue traceable to v0.9.0 in 2018, a Kustomize remote reference abused through git fetch --upload-pack since v2.7.0, and Helm plugin execution via configHome when --enable-helm is turned on. All of them create a confused-deputy problem: a developer confined to one namespace reaches a process holding every tenant's secrets, which is why a scope-change element appears in all four CVSS vectors.

Command injection through SSH proxy URLs

CVE-2026-55797 (GHSA-j6cw-g6p4-7hch, CWE-78) is a command injection. When an SSH Git repository is configured with a proxy URL, the proxy host and port were copied into an SSH ProxyCommand without validation, so a hostname containing shell metacharacters could break out and run code inside the repo server. Every release from v2.11.0 is affected; the behavior arrived in January 2024 with SOCKS5 proxy support. Triggering it takes only the ability to create a repository or credential template, including project-wide repository permissions. The fix enforces an allowlist: socks5 or socks5h schemes, a non-empty host, a port between 1 and 65535, and hostnames built solely from letters, digits, dots and hyphens.

Hook bypass undermines multi-tenancy

For shared installations, CVE-2026-77459 (GHSA-fmxq-cgp8-87wp, CVSS 9.9, CWE-863) may be the most consequential. Argo CD normally checks that an Application conforms to its AppProject before resources are created, but the PreDelete and PostDelete hooks skip that verification and run with the Application Controller's credentials on the target cluster. The advisory notes that this access is typically broad enough for a tenant to create cluster-scoped objects such as a ClusterRoleBinding, and that the PostDelete path has never enforced the project check since v2.10.0.

An unauthenticated RCE that remains unpatched

Separately, a repo-server flaw that became public on July 1, 2026 still has no fix. Synacktiv researchers demonstrated an unauthenticated remote code execution they named the Octopus Trap: the repo server's internal gRPC service does not authenticate callers, so a crafted GenerateManifest request can redirect the Kustomize options --enable-helm and --helm-command toward a script hosted in an attacker's repository. Anyone who can reach the port gets a shell; The Hacker News reported that the flaw could enable cluster takeover. Synacktiv says it disclosed the bug in January 2025, leaving it open for roughly 18 months. After gaining code execution, an attacker can read the Redis password from the environment, poison the manifest cache and have the Application Controller deploy attacker-controlled work on the next sync — a replay of CVE-2024-31989. Because the official Helm chart ships with networkPolicy.create set to false, many Helm-based installs have no network fence around the repo server or Redis.

What operators should do now

The dev.to analysis recommends upgrading to v3.3.15, v3.4.10 or v3.5.4 using the signed release artifacts (Cosign, SLSA Level 3), noting that Argo CD 2.x and versions 3.0 through 3.2 are out of support and will never receive these patches. Operators should enable NetworkPolicies so only Argo CD's own components can reach the repo server and Redis, avoid granting repository create or update rights to untrusted users, and watch for unexpected shells and Git clones in the repo server, unexplained Redis access, and syncs without a matching commit.

Why it matters

Argo CD is the workhorse of Kubernetes GitOps — 93 percent of respondents in the 2023 Argo community survey said they run it in production. This episode shows that the repo server, a component parsing untrusted repository content while holding every tenant's credentials, deserves tier-zero treatment, and that severity and scanner visibility are unrelated: three of the four most dangerous bugs are invisible to CVE-driven tooling, and one known unauthenticated RCE is still waiting for a fix. Network isolation and least-privilege repository access are the defenses that hold even when a CVE number never arrives.