Argo CD Path Traversal via Malicious Helm Chart values.ya...

In January 2022, security researchers at Apiiro disclosed CVE-2022-24348, a path traversal vulnerability in Argo CD that let an attacker weaponize a malicious Helm chart's values.yaml file to break out of the intended application directory and load Kubernetes manifests, secrets, or configuration from anywhere Argo CD had repository access to. In a GitOps continuous delivery tool that's often wired directly into production clusters and multiple Git repositories, that's a meaningful blast radius: a single crafted chart could be used to read sensitive files belonging to other applications managed by the same Argo CD instance, including credentials and other secrets never meant to be exposed to that tenant.

The bug matters less for its raw technical complexity — it's a classic path traversal, one of the oldest bug classes in software — and more for where it landed: the control plane orchestrating deployments across a Kubernetes fleet. Argo CD sits at a trust boundary between Git repositories (often multi-tenant) and live clusters, which is exactly the kind of chokepoint that supply chain attackers look for.

What CVE-2022-24348 Actually Does

Argo CD supports Helm as one of its supported templating engines for GitOps-style Kubernetes CD. When Argo CD renders a Helm chart, it merges the chart's default values.yaml with any values files referenced by the Argo CD Application resource. The vulnerability lived in how Argo CD resolved the path to a chart's values.yaml: by supplying a value that referenced a relative path (using ../ sequences), an attacker who controlled a Helm chart definition could point Argo CD outside the chart's own directory and cause it to load and render an arbitrary YAML file from elsewhere on the filesystem the Argo CD repo-server had checked out.

Because Argo CD's repo-server often has multiple Git repositories checked out locally — sometimes belonging to different applications, teams, or even different tenants sharing the same Argo CD instance — path traversal here is not a theoretical "read /etc/passwd" bug. It's a way to pull another application's manifests, its values.yaml, or Kubernetes Secrets referenced in that repository into the rendered output of the attacker's own application, effectively exfiltrating data across an intended isolation boundary. In shared or multi-tenant Argo CD deployments — a common pattern for platform teams running GitOps at scale — this made CVE-2022-24348 a genuine tenant-isolation break, not just a local file-read.

Affected Versions and Components

The vulnerability affects Argo CD's Helm chart rendering path across the 2.x line prior to the patched releases. The Argo CD maintainers shipped fixes in:

• Argo CD 2.3.0 (via release candidate 2.3.0-rc4)
• Argo CD 2.2.4
• Argo CD 2.1.9

Versions of Argo CD prior to these patch releases that support Helm chart applications are considered vulnerable. The issue is tracked upstream as GitHub Security Advisory GHSA-4nq9-27hp-cnxp in the argoproj/argo-cd repository. Because the flaw is in Argo CD's own repo-server/Helm handling rather than in a third-party dependency, every deployment method — self-hosted, Argo CD Autopilot, or managed offerings built on top of upstream Argo CD — needed the same core fix, though downstream distributions and Helm charts for Argo CD itself may have lagged behind the upstream patch dates.

CVSS, EPSS, and KEV Context

Argo CD's advisory rates CVE-2022-24348 as High severity, with a CVSS v3.1 base score in the high-7 range, reflecting a network-exploitable issue with low attack complexity that requires some level of privilege (the ability to define or modify an Argo CD Application/Helm chart source) but that can compromise confidentiality of data outside the attacker's intended scope. The core drivers of the score are the network attack vector, low complexity, and a scope change — the impact extends beyond the component the attacker directly controls, which is precisely why cross-tenant secret exposure is the headline risk.

As of this writing, CVE-2022-24348 has not been added to CISA's Known Exploited Vulnerabilities (KEV) catalog, and there is no confirmed evidence of mass in-the-wild exploitation. That said, absence from KEV shouldn't be read as "safe to ignore." Argo CD is widely deployed as the GitOps engine of choice for Kubernetes CD, and vulnerabilities in cluster-connected control planes tend to draw sustained attacker interest even without a documented mass-exploitation campaign — EPSS-style exploit-prediction signals for infrastructure tooling CVEs like this one can shift quickly once public proof-of-concept exploitation details circulate, so it's worth tracking rather than assuming permanent low risk.

Timeline

• Discovery — Researchers at Apiiro identified the path traversal behavior in Argo CD's Helm values handling during research into GitOps and Kubernetes CD supply chain risks, alongside related findings affecting other Argo CD components disclosed around the same period.
• Coordinated disclosure — The finding was reported to the Argo project maintainers through their security disclosure process ahead of public release.
• January 30, 2022 — Argo CD's maintainers published the security advisory (GHSA-4nq9-27hp-cnxp) alongside patched releases 2.1.9, 2.2.4, and 2.3.0-rc4, and CVE-2022-24348 was assigned and made public.
• Post-disclosure — Downstream Argo CD distributions, Helm charts, and managed GitOps platforms rolled the fix forward into their own release trains over the following weeks, and the finding became a frequently cited example in Kubernetes and GitOps security guidance about the risks of untrusted Helm charts in shared CD tooling.

Remediation Steps

1. Upgrade Argo CD. Move to 2.3.0 or later, or apply the patched 2.1.9 / 2.2.4 releases if you're pinned to an earlier minor line for compatibility reasons. This is the definitive fix — there is no reliable configuration-only mitigation that fully closes the path traversal.
2. Audit who can define Application sources. Because exploitation requires the ability to point Argo CD at a malicious Helm chart, tightening RBAC on who can create or modify Application and AppProject resources reduces the practical attack surface while you roll out patches.
3. Enforce project-level source restrictions. Use Argo CD AppProject sourceRepos and destination restrictions to limit which repositories and paths a given team's applications can reference, reducing the value of any traversal even against unpatched instances.
4. Segment multi-tenant Argo CD instances. If multiple teams or customers share a single Argo CD control plane, evaluate whether stronger isolation (separate repo-servers, separate instances, or namespace-scoped Argo CD) is warranted given how directly this bug undermined tenant boundaries.
5. Review Helm chart provenance. Treat third-party or externally contributed Helm charts consumed via GitOps the same way you'd treat any other third-party dependency — pin versions, review diffs, and avoid resolving charts from untrusted or loosely controlled sources.
6. Check for exposure after the fact. If you ran an affected Argo CD version with multi-tenant repository access before patching, review Argo CD repo-server and application-controller logs for anomalous Helm rendering activity or unexpected values-file references, and rotate any secrets that may have been reachable across application boundaries.

How Safeguard Helps

CVE-2022-24348 is a good illustration of why supply chain security can't stop at scanning application dependencies — the GitOps and Kubernetes CD tooling itself is part of the software supply chain, and a path traversal there can leak the very secrets your dependency scanning is trying to protect.

Safeguard is built to close that gap. We continuously inventory the CD and GitOps tooling in your environment — Argo CD included — against known CVEs like this one, so a vulnerable Argo CD instance doesn't sit unpatched simply because it's "infrastructure" rather than "application code." Beyond version tracking, Safeguard evaluates the configuration risk this CVE exploited: overly broad AppProject source permissions, shared repo-server access across tenants, and Application resources with loosely scoped Helm sources, surfacing these as prioritized findings rather than leaving them buried in YAML.

When a CVE like CVE-2022-24348 is disclosed, Safeguard's monitoring flags affected Argo CD deployments in your fleet immediately, correlates them with CVSS and exploit-likelihood signals, and routes remediation guidance to the teams that own the cluster — turning "patch Argo CD before it's exploited" from a manual audit into an automated, continuously enforced part of your GitOps and Kubernetes CD security posture.