# Argo CD CVE-2026-113708: Read-Only Users Can Run Code on the Repo-Server. Upgrade to 3.4.10+

URL: https://www.devopsness.com/blog/argo-cd-cve-2026-113708-repo-server-rce
Author: Kiril Urbonas
Published: 2026-11-08
Updated: 2026-11-08
Categories: DevOps
Tags: ArgoCD, CVE, GitOps, Security, News

Summary: Three CVSS 9.9 Argo CD repo-server bugs can be reached by anyone with Application get, the permission most teams hand to every viewer. Fixed versions, the v2 and 3.3 support cliff, and the RBAC and config checks to run today.

---
# Argo CD CVE-2026-113708: Read-Only Users Can Run Code on the Repo-Server. Upgrade to 3.4.10+

Upgrade Argo CD to 3.4.10, 3.5.4 or 3.6.0 or later. Three CVSS 9.9 repo-server bugs, two that run commands and one that reads files, are reachable by any user who can `get` an Application, which in many installs means every logged-in viewer. Argo CD v2 gets no fix, and 3.3 left support on November 3.

> [!VERIFIED]
> Argo CD 3.3.15, 3.4.10, 3.5.4, 3.6.0-rc2 and the later 3.3.19, 3.6.0 and 3.6.1 releases, against GHSA-9v9p-x54c-58gc, GHSA-fw5c-w8rc-j7fx, GHSA-m3vr-7329-44ww, GHSA-j6cw-g6p4-7hch, the CVE records for CVE-2026-113708, 113709 and 113672, the GitHub release pages, and the Argo CD RBAC, Kustomize and release-cadence docs. Checked November 8, 2026.

## Three bugs, one front door

The Argo CD team shipped the fixes on October 6, 2026, published the advisories on October 7, and the CVE records followed on October 20. All three are scored 9.9 (`AV:N/AC:L/PR:L/UI:N/S:C`) and all three live in `argocd-repo-server`, the component that clones your Git repositories and renders manifests.

| CVE | Advisory | What it does | Affected from | Precondition |
|---|---|---|---|---|
| CVE-2026-113708 | GHSA-9v9p-x54c-58gc | A Kustomize remote base `ref` or `version` starting with `-` becomes a `git fetch` option (`--upload-pack`), so a `file://` remote runs a command | v2.7.0 | Kustomize 5.x, the bundled default |
| CVE-2026-113709 | GHSA-fw5c-w8rc-j7fx | `helmGlobals.configHome` points Helm at a repo-controlled plugin directory, and Helm runs the plugin | v2.1.0 | `--enable-helm` in `kustomize.buildOptions` |
| CVE-2026-113672 | GHSA-m3vr-7329-44ww | Jsonnet `import`, `importstr` and `importbin` open any path the process can read | v0.9.0 | Jsonnet enabled, the default |

The first two run commands as the repo-server user. The third is a file read, but its advisory lists what it reaches: `/proc/self/environ`, the projected service-account token, mounted private keys and repository credentials. Argo CD redacts generated Secrets, so the trick is to drop the file contents into a ConfigMap, which comes back unredacted.

The second delivery path is what makes these bad. Besides committing a file to a repository an Application builds, an attacker can upload it through `POST /api/v1/applications/manifestsWithFiles`, the endpoint behind `argocd app diff --local --server-side-generate`. Each advisory says the same thing about that path: it needs only Application `get` on an existing Application (a directory Application for the Jsonnet bug), not update, sync or Git write access.

## Why "read-only" is the wrong mental model here

The repo-server holds every Git, Helm and OCI credential Argo CD uses. A command running inside it can read all of them, which turns one viewer account into access to every repository your GitOps setup can pull. And `get` is the permission teams hand out most freely: the built-in `role:readonly` grants read access to all resources, and many installs set `policy.default: role:readonly` so every SSO user lands there. The RBAC docs note that access from `policy.default` cannot be blocked by a `deny` rule.

There is also no egress story to fall back on. For CVE-2026-113708, `file://` never leaves the pod, and the advisory says plainly that blocking repo-server egress does not prevent it.

## Am I affected?

Run these against the cluster that hosts Argo CD. The first two lines come from the advisories' own conditions; the RBAC and repository greps are ours.

```bash
# 1. Running version (fixed: 3.4.10+, 3.5.4+, 3.6.0+; 3.3.15+ is fixed but end of life)
$ kubectl -n argocd get deploy argocd-repo-server \
    -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

# 2. Is Helm-through-Kustomize on (CVE-2026-113709), and is Jsonnet on (113672)?
$ kubectl -n argocd get cm argocd-cm -o jsonpath='{.data.kustomize\.buildOptions}{"\n"}'
$ kubectl -n argocd get cm argocd-cm -o jsonpath='{.data.jsonnet\.enable}{"\n"}'   # empty means enabled

# 3. Who gets Application get by default? A readonly default means everyone who logs in
$ kubectl -n argocd get cm argocd-rbac-cm -o jsonpath='{.data.policy\.default}{"\n"}'
$ kubectl -n argocd get cm argocd-rbac-cm -o jsonpath='{.data.policy\.csv}' | grep -E 'applications, *(get|\*)'

# 4. Confirm what a given role can actually do, using the live ConfigMap
$ argocd admin settings rbac can role:readonly get applications '*/*' --namespace argocd

# 5. Look for payload shapes already committed to your manifest repos
$ git grep -nE '[?&](ref|version)=-' -- '*.yaml' '*.yml'
$ git grep -n 'configHome' -- '*.yaml' '*.yml'
$ git grep -nE 'import(str|bin)? *["'"'"'](/|\.\./)' -- '*.jsonnet' '*.libsonnet'
```

A hit in step 5 is not proof of an attack, and a clean result proves nothing about the upload path, which leaves no trace in Git.

## What to do now

**Upgrade.** Every Argo CD version from v0.9.0 onward is exposed to at least the Jsonnet bug, every one from v2.7.0 to the first bug as well, and the only complete fix is a patched release. The fixed floor is 3.3.15, 3.4.10, 3.5.4 and 3.6.0-rc2. As of November 8 the newest patches are 3.4.13, 3.5.7 and 3.6.1, and 3.6.0 went GA on November 3 with the fixes included. Skip 3.3 as a target: its 3.3.19 release notes say the series reached end of life on November 3, 2026. Read the upgrade notes for every minor you cross; we covered the habits that keep those upgrades boring in [our Argo CD best practices guide](/blog/gitops-with-argo-cd-best-practices-for-2025).

**Until the upgrade lands, close what you can:**

- **Turn off `--enable-helm` if nothing needs it.** The CVE-2026-113709 advisory calls removing it from `kustomize.buildOptions` a complete workaround for that bug. Apps that render Helm charts through Kustomize break.
- **Set `jsonnet.enable: "false"` in `argocd-cm` if you do not use Jsonnet.** That covers both the Git and upload paths for CVE-2026-113672. Watch out: Jsonnet files are skipped silently, so a directory app that is all Jsonnet syncs with nothing in it.
- **Pin Kustomize below 5.0 for CVE-2026-113708, only if you can live with it.** Register a 4.5.7 binary with `kustomize.path.v4.5.7` and set `spec.source.kustomize.version` on every Kustomize Application. Leaving 5.x as the default or as another registered version keeps the hole open, and apps that use Kustomize 5 features fail.
- **Shrink Application `get`.** Move `policy.default` off `role:readonly`, scope `get` to the projects people actually work in, and block `POST /api/v1/applications/manifestsWithFiles` at your ingress, plus the gRPC method `/application.ApplicationService/GetManifestsWithFiles` the CLI calls, if nobody uses server-side local diffs.

After changing `kustomize.buildOptions`, restart the repo-server; the Kustomize docs warn you may need a restart for the change to take effect. Expect the sync status to shift on apps that lose a tool, and use [our OutOfSync debugging steps](/blog/argo-cd-app-outofsync) to tell a real drift from a rendering change.

## Where this breaks

RBAC and the ingress block close only the upload path. Anyone who can push to a repository an Application builds can still commit the same Kustomization or Jsonnet file, and it runs on the next sync. That includes every team with write access to its own app repo. The Kustomize pin is fragile for the reason the advisory gives, and there is no workaround at all for CVE-2026-113708 on Kustomize 5. After upgrading, rotate the Git, Helm and OCI credentials stored in Argo CD if anyone you do not fully trust held `get` before the patch; there is no reliable way to prove the upload path was not used.

## Questions people ask

### Does Argo CD 2.x get a fix for CVE-2026-113708?

No. The advisories list no patched v2 version, and the Argo CD advisory for the related CVE-2026-55797, published the same day, states that 2.x and 3.0 through 3.2 are out of support and will not receive a patch. The project patches only the three most recent minors, which since November 3 are 3.4, 3.5 and 3.6. A v2 install has to migrate to 3.4 or newer.

### Is Argo CD affected if --enable-helm is off?

Partly. CVE-2026-113709 needs `--enable-helm` in `kustomize.buildOptions`, so installs without it escape that one. CVE-2026-113708 needs only Kustomize 5.x, bundled since v2.7.0, and CVE-2026-113672 needs only Jsonnet, enabled by default. Turning Helm off removes one of the three, not the urgency.

### Can I block CVE-2026-113708 with a NetworkPolicy?

No. The exploit uses a `file://` remote, which Git handles inside the repo-server pod without any network connection, so egress rules have nothing to stop. Network controls in front of `argocd-server`, such as blocking the `manifestsWithFiles` endpoint, cut the upload path only. Malicious Kustomizations committed to Git are still built on sync.

## The decision, concretely

- **On 3.4, 3.5 or 3.6 below the fixed patch?** Upgrade within the patch line today; it is the smallest change that closes all three.
- **On 3.3.15 or later?** You are patched, but 3.3 is end of life, so plan the move to 3.4 or newer now.
- **On v2 or 3.0 to 3.2?** No patch is coming. Apply the workarounds that fit, cut `get` to deployers, and schedule the migration this sprint.

## The call we'd make

Upgrade to the latest 3.4, 3.5 or 3.6 patch this week, and treat any remaining v2 or 3.3 install as the forcing function for the v3 migration you were going to do anyway. Until then, turn off Jsonnet and `--enable-helm` wherever nothing depends on them and move `policy.default` off `role:readonly`. The caveat: none of that stops a malicious commit to an app repo, so the upgrade, followed by a credential rotation, is the only real close.

## Sources

- [Argo CD: GHSA-9v9p-x54c-58gc, a Kustomize remote ref can run commands in the repo-server (CVE-2026-113708)](https://github.com/argoproj/argo-cd/security/advisories/GHSA-9v9p-x54c-58gc)
- [Argo CD: GHSA-fw5c-w8rc-j7fx, a Kustomize Helm config home can run commands in the repo-server (CVE-2026-113709)](https://github.com/argoproj/argo-cd/security/advisories/GHSA-fw5c-w8rc-j7fx)
- [Argo CD: GHSA-m3vr-7329-44ww, a Jsonnet import can read files from the repo-server (CVE-2026-113672)](https://github.com/argoproj/argo-cd/security/advisories/GHSA-m3vr-7329-44ww)
- [Argo CD: v3.3.19 release notes, final 3.3 release](https://github.com/argoproj/argo-cd/releases/tag/v3.3.19)