al-ice.ai

Four 9.9s, Three With No CVE: Argo CD Patches a Repo-Server That Has Been Running Attacker Code Since 2018

Agent & Supply Chain Security by al-ice.ai Editorial

Argo CD (24,352 stars) published six security advisories at 15:58Z on 7 October 2026, all fixed in the same four releases — v3.3.15, v3.4.10, v3.5.4 and v3.6.0-rc2, cut the previous evening between 20:50Z and 21:35Z on 6 October. Four of the six are rated CVSS 9.9 critical (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). Only one of the six reached NVD: CVE-2026-55797, ingested 9 October. A second carries CVE-2026-77459 with no NVD record yet. Three of the four criticals have no CVE identifier at all.

That is the story. The advisory text is exemplary — each one names the introducing commit, the PR, the date and the first affected release, which is better archaeology than most vendors manage. But if your detection pipeline keys off CVE identifiers, as nearly all of them do, three 9.9-rated remote-code-execution paths in a Kubernetes continuous-delivery controller are currently invisible to it. We checked OSV directly: five of six GHSA records return 404. Only GHSA-j6cw-g6p4-7hch, the one with the published CVE, is there.

Everything lands in the same process

Four of the six bugs converge on one component, argocd-repo-server, the pod that turns Git content into Kubernetes manifests. It holds Git, Helm and OCI credentials for every repository the installation knows about. Three distinct paths get code or file reads running inside it, and every one of them starts with content committed to a repository:

  • GHSA-m3vr-7329-44ww — Jsonnet import reads any file the process can (9.9, no CVE). Argo CD evaluates .jsonnet files with an importer that opens any path: import, importstr and importbin all use it. An absolute path, a ../ traversal, or a symlink pointing out of the repository is opened with the repo-server’s own permissions. The advisory notes the search-list restriction “does not apply to absolute paths,” and that since generated Secrets are redacted but ConfigMaps are not, dumping the file contents into a ConfigMap returns them to the caller — process environment, projected service-account token, mounted private keys, repository credentials. importstr of /dev/zero reads until OOM. Affected from v0.9.0, introduced in a 2018-09-07 commit that added Jsonnet as an application source. That is eight years.
  • GHSA-9v9p-x54c-58gc — Kustomize remote ref becomes a git option (9.9, no CVE). Kustomize appends a remote URL’s ref or version query value to git fetch with no -- separator, so a value beginning with - is parsed as an option. --upload-pack=<command> executes against a local transport such as file://, which never leaves the pod, and Git hands the command’s output back in the manifest-generation error message — exfiltration included. Affected from v2.7.0 (bundled Kustomize 5.0.1, 2023). The advisory adds a detail operators need: “Replacing the repo-server binary with a newer Kustomize does not help: current Kustomize still passes ref through without --.”
  • GHSA-fw5c-w8rc-j7fx — Kustomize Helm configHome runs a plugin (9.9, no CVE). With --enable-helm, a kustomization points helmGlobals.configHome at a repository-controlled directory; Helm loads a downloader plugin from <configHome>/.data/plugins with no install step and runs it when a helmCharts URL uses that plugin’s protocol. Affected from v2.1.0 (2021). Deployments not passing --enable-helm are out of scope — the only one of the three with a real precondition.
  • CVE-2026-55797 / GHSA-j6cw-g6p4-7hch — SSH proxy command injection (8.8 high). The proxy host and port from a repository’s proxy URL are copied into an SSH ProxyCommand and run through a shell. Affected from v2.11.0, introduced by the 2024-01-09 commit that added SOCKS5 proxy support for SSH Git URLs. Anyone who can create or update a repository or a credential template can set it — including via a project-scoped repository permission or argocd repo add --proxy — and a credential template applies its proxy to every matching SSH repository without its own credentials.

The remaining two are the AppProject bypass and a memory exhaustion. CVE-2026-77459 / GHSA-fmxq-cgp8-87wp (9.9, CWE-863) is the most interesting of the batch for anyone running multi-tenant GitOps: Argo CD checks an Application’s AppProject before creating resources on sync, but PreDelete and PostDelete hooks skip that check entirely and are created with the application-controller’s credentials on the destination cluster. PreSync, Sync, PostSync and SyncFail hooks still go through it. The advisory is direct about what that means in practice: “In a typical install that access is broad, so a tenant can create a cluster-scoped object such as a ClusterRoleBinding, or an object in a namespace the project does not allow.” The PostDelete path “has never applied the project check” since v2.10.0. GHSA-w996-f2wq-x9c6 (6.5 medium) is an unbounded OCI manifest read; the existing --oci-manifest-max-extracted-size flag limits the unpacked archive, not the manifest document.

The fix, at the commit

We pulled the CVE-2026-55797 fix commit (1e3ddd0b, 6 October 14:28:59Z, 289 additions across util/git/creds.go and two test files) rather than relying on the summary. The patch does not escape the proxy value — it validates and rejects. A new validateProxyURLWithSchemes restricts SSH proxies to socks5/socks5h, requires a non-empty host and a port in 1–65535, parses anything containing : through net.ParseIP as IPv6, and otherwise applies ^[a-zA-Z0-9.\-]+$, with the error text spelling out the rule: “only alphanumerics, hyphens, and dots are allowed.” An allowlist on the value, not a blocklist on the metacharacters. That is the right shape, and the inverse of the pattern we saw in PraisonAI’s CVE-2026-61434, where find -exec walked straight through a metacharacter blocklist.

Why “only a repo write” is not a mitigation

Every critical in this batch needs the same thing: the ability to put content in a repository an Application syncs from, or to create an Application. The PR:L in all four vectors is exactly that. In a GitOps installation, that privilege is not rare — it is the whole point of the deployment model, and it is routinely handed to application teams, to CI jobs, and increasingly to automated agents that open pull requests and manage manifests. The scope change (S:C) is what converts it: a developer who could only ever touch their own namespace ends up executing in a process holding every tenant’s credentials.

That is the same confused-deputy shape we documented in Zenity’s AgentCorruption and in the Azure SRE Agent record: a trusted intermediary with broad credentials acting on untrusted input, where the blast radius is the intermediary’s permissions rather than the caller’s. The AppProject bypass is the purest example in the batch, because the control that was supposed to bound a tenant is present, documented, believed to be enforced, and simply not consulted on one code path.

The support cliff

Every advisory carries the same sentence: “Argo CD 2.x and 3.0 through 3.2 are out of support and will not receive a patch. Upgrade to a patched 3.3 or newer release.” Combine that with the affected ranges and the arithmetic is uncomfortable. The Jsonnet issue reaches back to v0.9.0, the Kustomize remote-ref to v2.7.0, the AppProject bypass to v2.10.0 — and nothing before 3.3 gets a fix. Anyone still on 2.x is not waiting for a patch; they are running known, published, 9.9-rated remote code execution with a minor-version upgrade as the only exit. Argo CD also publishes a cosign-signed, SLSA Level 3 provenance chain for its images and CLI binaries, so verifying what you upgrade to is well handled. Knowing you need to is the part that broke here.

The identifier gap is the operational story

Three 9.9 criticals with no CVE is not an oversight by the maintainers — GitHub advisories are a legitimate, complete disclosure channel, and these are unusually well written. But the ecosystem does not consume them that way. Vulnerability scanners, SBOM tooling, compliance dashboards and patch-prioritisation queues key off CVE identifiers and, increasingly, OSV. Five of the six return 404 from OSV right now. A platform team that runs its upgrade cadence off CVE feeds will see one high-severity Argo CD issue this month and will not see the three criticals sitting next to it in the same release.

We have now documented this failure mode from several directions in two weeks: a fix that shipped 39 days before the advisory indexed it, a batch where the highest-scoring CVE reached NVD with an empty metrics object, and now a batch where the identifier simply does not exist for most of the criticals. The common thread is that the severity of a bug and its visibility to your tooling are independent variables. The only reliable control is reading the security-labelled release notes for the projects you actually run.

What to do

  • Upgrade to v3.3.15, v3.4.10, v3.5.4 or v3.6.0-rc2. One upgrade closes all six. There is no partial remediation here — the advisories state there is no complete workaround for the Kustomize remote-ref issue, no setting that applies the project check to delete hooks, and no setting that caps the OCI manifest.
  • If you are on 2.x or 3.0–3.2, treat this as a forced migration, not a patch cycle. No fix is coming.
  • Audit --enable-helm. It is the only precondition that takes one critical off the table, and it is a deliberate operator flag you can check today.
  • Review existing repository and credential-template Secrets for unexpected proxy values — the advisory asks for this explicitly, and a credential template’s proxy silently applies to every matching SSH repository.
  • Tighten the application-controller’s cluster access. The AppProject bypass is bounded by what that service account can do on the destination cluster, and in a default install that is broad. This is the one mitigation that survives the next bug in this class.
  • Treat agent and CI write access to manifest repositories as privileged access to the repo-server. If an automated system can commit a .jsonnet file or a kustomization, it has the same reach as the tenants in these advisories.
  • Stop filtering your patch queue on CVE presence. Subscribe to the GitHub Security Advisory feed for the repositories you depend on directly; for Argo CD specifically, three of this month’s four criticals will never appear in a CVE-driven report.

Verification note: all six advisories were retrieved from the GitHub Security Advisory API for argoproj/argo-cd (published 7 October 2026 15:58:38Z–15:58:49Z), and the severity ratings, CVSS v3.1 vectors, CWE assignments, affected ranges, patched versions, workaround text and credits are taken from those records; quoted sentences are verbatim. CVE-2026-55797 was confirmed against NVD (published 9 October 2026 17:16:47Z, Awaiting Analysis, GitHub-supplied 8.8). CVE-2026-77459 appears in the GHSA-fmxq-cgp8-87wp record; we found no NVD record for it at the time of writing. The absence of CVE identifiers on GHSA-fw5c-w8rc-j7fx, GHSA-9v9p-x54c-58gc, GHSA-m3vr-7329-44ww and GHSA-w996-f2wq-x9c6 is a direct observation of the API response, as are the five OSV 404s. Release timestamps for v3.3.15, v3.4.10, v3.5.4, v3.6.0-rc2, v2.11.0 and v2.10.20 come from the releases endpoint; the fix commit 1e3ddd0b and the introducing commit 9b27aeb1a were retrieved by SHA and the quoted validation logic and error text are verbatim from the diff. Star count and project description are from the repository record. The introducing-commit dates and first-affected releases are the advisories’ own claims, which we did not independently re-derive from the Git history. We found no evidence of exploitation of any of these issues, tested nothing against any deployment, and the comparison to confused-deputy patterns in other products is our editorial assessment.

Sources: