CVE-2026-113672 in Argo CDinfo

Summary

by MITRE • 10/20/2026

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. From 0.9.0 until 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2, the repo-server evaluates .jsonnet files with an importer that does not confine import, importstr, or importbin to the repository root. Absolute paths, parent-directory traversal, and repository symlinks can open any file readable by the repo-server, including /proc/self/environ, projected service-account tokens, mounted private keys, and repository credentials. Although generated Secrets are redacted, placing imported contents in a ConfigMap returns the data to the caller. Using importstr on a non-terminating device such as /dev/zero can exhaust repo-server memory. An attacker can commit a .jsonnet file to a Git repository used by an Application or upload the file through POST /api/v1/applications/manifestsWithFiles, also exposed by argocd app diff --local --server-side-generate. Directory applications evaluate every .jsonnet file in the application directory. The upload path requires only Application get permission on an existing directory Application, without Application update or sync permission or repository write access. This issue is fixed in versions 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Analysis

by VulDB Data Team • 10/20/2026

Argo CD serves as a declarative continuous delivery tool for Kubernetes that relies on GitOps principles to manage application deployments. A critical security vulnerability was identified in the repo-server component across versions from 0.9.0 through specific patched releases including 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2. The core technical flaw resides within the jsonnet evaluation engine used by the repo-server to process application manifests stored in Git repositories. Specifically, the importer logic responsible for handling .jsonnet files fails to enforce strict path confinement. This deficiency allows an attacker to utilize absolute paths, parent-directory traversal sequences such as ../, and repository symlinks to escape the intended repository root directory. Consequently, this lack of isolation enables arbitrary file read access to any resource accessible by the repo-server process on the underlying host system.

The operational impact of this vulnerability is severe due to the high privileges typically held by Argo CD service accounts within a Kubernetes cluster. The repo-server often runs with permissions that allow it to read sensitive infrastructure files, including projected service-account tokens mounted in pods, private keys used for signing or encryption, and repository credentials stored in configuration maps. By exploiting the path traversal flaw, an attacker can extract these secrets directly from the file system. Although Argo CD attempts to mitigate data leakage by redacting generated Secrets during standard operations, this protection is bypassed when imported content is placed into a ConfigMap instead of a Secret. This mechanism inadvertently returns sensitive data back to the caller, effectively neutralizing the built-in sanitization efforts and leading to full credential exposure.

Beyond information disclosure, the vulnerability also presents a significant risk of denial-of-service attacks against the Argo CD infrastructure. An attacker can exploit the importstr function by targeting non-terminating character devices such as /dev/zero. Because jsonnet attempts to read the entire content of the specified file into memory for processing, feeding it an infinite stream causes rapid and unbounded memory consumption within the repo-server process. This resource exhaustion can lead to pod crashes or complete unavailability of the Argo CD server, disrupting continuous delivery pipelines and potentially causing broader outages in the Kubernetes cluster environment dependent on this tooling.

The attack surface for exploiting this vulnerability is broad due to multiple entry points available to authenticated users with limited permissions. An attacker who has write access to a Git repository managed by Argo CD can simply commit a malicious .jsonnet file that triggers the path traversal or resource exhaustion logic when the repo-server processes it during sync operations. Alternatively, an attacker does not need repository write access if they possess Application get permission on an existing directory-type application within Argo CD. By using the POST /api/v1/applications/manifestsWithFiles endpoint, which is also exposed via the argocd app diff --local --server-side-generate command, a user can upload arbitrary files directly to the repo-server for evaluation without needing Application update or sync permissions. This low-barrier access vector allows attackers with minimal privileges to execute remote code execution patterns that result in data exfiltration and service disruption.

From a classification perspective, this vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, as the application fails to restrict file system operations to an expected location. It also relates to CWE-400: Uncontrolled Resource Consumption due to the potential for memory exhaustion via infinite streams. In terms of adversary tactics, this exploit maps to ATT&CK technique T1537: Transfer Data to Cloud Account if leveraging external repositories, and more critically T1005: Data from Local System for stealing credentials stored on disk or in configuration files. The mitigation strategy involves upgrading Argo CD to the fixed versions listed above where path confinement has been strictly enforced. Organizations should also audit their RBAC policies to ensure that users with Application get permissions do not have unnecessary access to sensitive endpoints, and consider implementing network-level restrictions to limit repo-server outbound connections if possible.

Responsible

GitHub M

Reservation

10/20/2026

Disclosure

10/20/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!