Critical Argo CD Jsonnet flaw lets users with view access read tokens and keys…

What happened

Argo CD is a popular open source tool that automatically deploys applications to Kubernetes based on what is stored in a Git repository, an approach known as GitOps. One of its parts is the repo-server, which turns repository contents into application configuration, including files written in the Jsonnet format.

A flaw tracked as CVE-2026-113672 (EUVD-2026-105227 in the European database) was found in this component. When processing .jsonnet files, Argo CD does not check whether instructions to include another file stay inside the repository. A file can therefore load anything the repo-server is able to read, such as tokens, private keys or Git repository credentials.

The Argo CD team shipped fixed releases on October 6, and the vulnerability was published in the US NVD database on October 20, 2026. The same releases also fix other critical issues, including two Kustomize bugs that allow running commands on the repo-server. At the time of writing, the flaw is not listed in the CISA KEV catalog and the EUVD database does not record any active exploitation. No exploitation is known so far.

Why it is dangerous

This is a path traversal flaw (CWE-22), meaning a program can be tricked into reaching outside the folder it is supposed to stay in. Picture an archivist told to fetch documents from one shelf only. If someone hands over a note saying “go two floors up and bring me what is in the safe”, the archivist does it without asking. Jsonnet in Argo CD behaves the same way: it happily loads files from outside the repository.

The attack works over the network and needs only minimal privileges. It is enough to be able to commit a file to a Git repository that Argo CD uses, or to have permission to merely view an existing Directory-type application in Argo CD. In the second case, no permission to change or sync the application is needed, and no repository write access either. Argo CD does hide Secret objects in its response, but content placed in a ConfigMap comes back to the attacker in plain form.

What an attacker can obtain or cause:

environment variables of the repo-server process, which may contain passwords and keys
Kubernetes service account tokens mounted into the repo-server
mounted private keys and Git repository credentials
memory exhaustion of the repo-server, which disrupts its work

The CVSS score is 9.9 out of a maximum of ten, which means critical severity. CVSS is an international scale that rates how easy a flaw is to exploit and how much damage it can do. The high score reflects that the attack is simple, works over the network and its impact reaches beyond Argo CD itself.

EPSS is a model that estimates the probability that a flaw will be exploited in the next 30 days. As of October 28, 2026, the estimate for this flaw is under 1 percent, roughly eight in a thousand. The CISA KEV catalog is a US list of flaws known to be actively exploited, and this one is not on it yet. That is no reason to delay the update, because the flaw is now publicly described.

Who is affected

All Argo CD versions from 0.9.0 up to, but not including, 3.3.15, 3.4.10, 3.5.4 and 3.6.0-rc2 are affected. In practice that means almost every installation that has not yet been moved to one of the fixed releases.

Argo CD typically runs in companies that operate their own or cloud-based Kubernetes clusters and deploy applications the GitOps way. The risk is highest where several teams or outside contractors share one Argo CD, or where every logged-in user can view applications. Installations whose web interface or API is reachable from the internet are also at higher risk.

Organizations that do not use Argo CD are not affected. If a supplier or a managed platform provider runs Argo CD for you, ask them whether they have already updated.

How to check if you are affected

You can see the version in the left-hand panel of the Argo CD web interface or from the command line. The commands below only read data and change nothing. If Argo CD does not run in the argocd namespace, adjust the name.

argocd version

The command prints both the client and server version, and the server version is what matters. You can also confirm it from the container images:

kubectl get deployments -n argocd -o wide

To see whether Jsonnet is enabled and who is allowed to view applications, look at the argocd-cm and argocd-rbac-cm configuration. If the jsonnet.enable key is missing, Jsonnet is enabled.

kubectl get configmap argocd-cm argocd-rbac-cm -n argocd -o yaml

If your server version is lower than the fixed release for your branch, you are affected. All branches older than 3.3 are affected as well.

How to fix it

The vendor fixed the flaw in versions 3.3.15, 3.4.10, 3.5.4 and 3.6.0-rc2. Proceed as follows:

Find your current server version as described in the previous section.
Update within your branch: from 3.3 to 3.3.15, from 3.4 to 3.4.10, from 3.5 to 3.5.4. Test installations running the pre-release should move to 3.6.0-rc2.
The vendor lists no fixed release for branches older than 3.3. Plan a move to a supported branch and read the official upgrading guide when changing branches.
Before updating, review changes that may break things: Kustomize builds that render Helm charts no longer honor helmGlobals.configHome, and an OCI manifest larger than 4 MiB is now rejected.
After the update, rotate sensitive data the repo-server could read: Git repository credentials, keys and tokens.

Until you update, you can reduce the risk. According to the Argo CD documentation, disabling config management tools you do not use can improve security. If you do not need Jsonnet, set the jsonnet.enable key in the argocd-cm ConfigMap to false. The vendor does not present this as an official workaround for this specific flaw, it is general hardening advice.

Also limit who can view applications in Argo CD and who can push to the repositories Argo CD deploys from. Update internet-facing instances first, followed by those shared by several teams or contractors.

What if you may already be compromised

Argo CD does not list specific indicators of compromise in the flaw description or the release notes. The flaw description does, however, point to where traces may appear:

.jsonnet files in your repositories that use import, importstr or importbin with absolute paths, paths containing .. or symbolic links
calls to the manifestsWithFiles API in the argocd-server logs. They are also produced by argocd app diff --local --server-side-generate. An attack along this path leaves no trace in the repository.
unexpected ConfigMap objects in application manifests
repeated repo-server restarts caused by running out of memory (OOMKilled)

The commands below only read data. The first searches the server logs, run the next two inside a cloned repository, and the last one shows repo-server restarts:

kubectl logs -n argocd -l app.kubernetes.io/name=argocd-server --tail=-1 --prefix | grep -i manifestswithfiles

grep -rnE --include='*.jsonnet' --include='*.libsonnet' "import(str|bin)?[[:space:]]*['\"](/|[^'\"]*\.\.)" .

find . -path ./.git -prune -o -type l -ls

kubectl describe pods -n argocd -l app.kubernetes.io/name=argocd-repo-server | grep -iE 'restart count|oomkilled'

Cluster logs are rotated over time, so search your central logging system too if you have one. If you find a suspicious file or a call from an unknown user, treat everything the repo-server could read as leaked and rotate it. If you find anything or are unsure, bring in a Kubernetes security specialist, because the leaked data may include service account tokens.

Sources

Articles are put together by an AI agent from public sources (vendors, CISA, ENISA, NVD, SK-CERT, NÚKIB), and version numbers and CVEs are checked against them automatically. Always confirm the steps in the vendor advisory before touching production.

Critical Argo CD Jsonnet flaw lets users with view access read tokens and keys from repo-server