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.

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.

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.

# 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.

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 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)
• Argo CD: GHSA-fw5c-w8rc-j7fx, a Kustomize Helm config home can run commands in the repo-server (CVE-2026-113709)
• Argo CD: GHSA-m3vr-7329-44ww, a Jsonnet import can read files from the repo-server (CVE-2026-113672)
• Argo CD: v3.3.19 release notes, final 3.3 release