SURIQ
Argo CD's repo-server is where GitOps puts its trust, and that is exactly why it keeps being the thing under attack. On October 7, 2026 the project shipped a coordinated security release fixing seven flaws, four of them rated CVSS 9.9, and three of those four land in that same repo-server. The short version for anyone running Argo CD: upgrade to v3.3.15, v3.4.10, v3.5.4, or v3.6.0-rc2 now, and treat the repo-server as the tier-zero component it has always been. We said the same thing in July about an unauthenticated code-execution path in the repo-server that had no patch at all. This time there is a patch, and the privilege bar to abuse several of these is lower than the headline CVSS numbers suggest.
| Advisory | CVSS | Component | What a low-privilege user gains |
|---|---|---|---|
| Kustomize Helm config home | 9.9 | repo-server | Runs a command |
| Kustomize remote ref | 9.9 | repo-server | Runs a command |
| Jsonnet import | 9.9 | repo-server | Reads credentials and files |
| AppProject delete-hook bypass (CVE-2026-77459) | 9.9 | app-controller | Creates disallowed cluster objects |
| SSH proxy injection (CVE-2026-55797) | 8.8 | repo-server | Runs a command |
| Oversized OCI manifest | 6.5 | repo-server | Exhausts memory (denial of service) |
| Extension proxy RBAC gap | 4.9 | API extensions | Cross-namespace access |
Why the repo-server is the target, again
The repo-server is the component that reads your Git repositories and renders them into Kubernetes manifests. To do that it runs real build tools, Kustomize, Helm, and Jsonnet among them, over content the user supplies. Any time a server executes a third-party toolchain against attacker-influenced input, the question is not whether a rendering trick can escape into command execution, but how many ways it can. Three of the four critical advisories are different answers to that question.
Two involve Kustomize. In one, a Kustomize build that has Helm rendering enabled can point Helm at a directory the repository controls and get a program from that directory to run inside the repo-server, according to the project's advisory. In the other, a remote resource URL smuggles a Git option into a fetch and runs a command, per a second advisory. The third, a Jsonnet import flaw, is not code execution but something nearly as bad for a shared service: an import can read files the process can reach, then return them to the caller through a ConfigMap. What an attacker can pull back, per the advisory, covers environment variables, the Kubernetes token mounted into the pod, any private keys on disk, and the credentials Argo CD stores for its repositories. That matters because the repo-server holds those credentials for every repository it serves. In a multi-tenant Argo CD, one tenant reading that process is reading everyone's secrets.
The privilege bar is lower than the CVSS line implies
Here is the part the wire recaps skip. For the two Kustomize flaws and the Jsonnet flaw, you do not need write access to a Git repository, and you do not need permission to sync or update an application. The advisories describe a second route: upload the malicious manifest through the POST /api/v1/applications/manifestsWithFiles endpoint, which backs argocd app diff --local --server-side-generate. That path needs only the Application get permission on an existing application. Read access to an app is a permission many teams hand out freely, on the assumption that reading is harmless. Here it is the whole attack surface.
The other two are more conventional but still internal. The SSH proxy command injection (CVE-2026-55797, CVSS 8.8) needs the ability to set a proxy on a repository or a credential template, which a project-scoped repository permission grants. The AppProject delete-hook bypass (CVE-2026-77459, CVSS 9.9) is the odd one out: it lives in the application-controller, not the repo-server. A user who can push a delete hook to an application's Git repository can create a Kubernetes object the AppProject was supposed to forbid, because PreDelete and PostDelete hooks skipped the project check that sync-time hooks pass through. Most installs give the controller broad cluster rights, so the object created can be a cluster-wide one, a ClusterRoleBinding being the obvious example.
Upgrade first, then shrink the blast radius
The fix is a version bump. Argo CD patched all seven issues in v3.3.15, v3.4.10, v3.5.4, and the v3.6.0-rc2 pre-release. There is a trap in the support matrix: Argo CD 2.x and the 3.0 through 3.2 lines have reached end of life, so no fix is coming for them even though they carry these bugs. If you are on one of those, the answer is an upgrade to a supported 3.3 or newer build, not a point release. As of this writing these were coordinated private disclosures and there are no public reports of exploitation in the wild, which is the window you want to patch inside.
Upgrading closes the specific holes. It does not change the fact that the repo-server is a shared, credential-bearing, code-running service, so pair the patch with two boundaries. Reduce who can reach it, and watch how it is reached. The project documents partial workarounds for operators who cannot upgrade instantly: disabling Jsonnet and not passing --enable-helm to Kustomize both close individual paths, though only if you do not rely on those features, and neither is a substitute for the patch. Restricting Application get and blocking the upload endpoint closes the low-privilege route but not a manifest committed to Git.
# argocd-server access log, the upload path that needs only Application get: POST /api/v1/applications/manifestsWithFiles # argocd-cm, close the two optional renderers the criticals abuse: data: jsonnet.enable: "false" kustomize.buildOptions: "" # ensure --enable-helm is not set here
Beyond that, watch the repo-server for what it should never do: spawn an unexpected child process, make an outbound connection it was not configured for, or render a manifest that fails in a way that leaks file contents. Command injection and remote code execution are the second most common flaw class our desk has logged across the last 90 days, behind only cross-site scripting, so a toolchain-rendering service that runs on user input is exactly where we expect to keep finding them. The GitOps lesson from Rancher Fleet and from Argo CD's own July disclosure holds: the thing that deploys your cluster is a path into your cluster, and it deserves the monitoring you give a domain controller.
What defenders should do this week
Patch to a supported, fixed release, confirm you are not sitting on an end-of-life 2.x or 3.0-to-3.2 build, and audit who holds Application get, repository-proxy, and Git-push rights on the repositories your applications sync from. Then decide whether the repo-server and application-controller have more Kubernetes access and more network reach than their job requires. Most do.