Where
-Infinity
0
Severity
8.4
EPSS
0.05%
CSRF
AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H

Impact

The Argo CD API prior to versions 2.10-rc2, 2.9.4, 2.8.8, and 2.7.16 are vulnerable to a cross-server request forgery (CSRF) attack when the attacker has the ability to write HTML to a page on the same parent domain as Argo CD.

A CSRF attack works by tricking an authenticated Argo CD user into loading a web page which contains code to call Argo CD API endpoints on the victim’s behalf. For example, an attacker could send an Argo CD user a link to a page which looks harmless but in the background calls an Argo CD API endpoint to create an application running malicious code.

Argo CD uses the “Lax” SameSite cookie policy to prevent CSRF attacks where the attacker controls an external domain. The malicious external website can attempt to call the Argo CD API, but the web browser will refuse to send the Argo CD auth token with the request.

Many companies host Argo CD on an internal subdomain, such as https://argo-cd.internal.example.com. If an attacker can place malicious code on, for example, https://test.internal.example.com/, they can still perform a CSRF attack. In this case, the “Lax” SameSite cookie does not prevent the browser from sending the auth cookie, because the destination is a parent domain of the Argo CD API.

Browsers generally block such attacks by applying CORS policies to sensitive requests with sensitive content types. Specifically, browsers will send a “preflight request” for POSTs with content type “application/json” asking the destination API “are you allowed to accept requests from my domain?” If the destination API does not answer “yes,” the browser will block the request.

Before the patched versions, Argo CD did not validate that requests contained the correct content type header. So an attacker could bypass the browser’s CORS check by setting the content type to something which is considered “not sensitive” such as “text/plain.” The browser wouldn’t send the preflight request, and Argo CD would happily accept the contents (which are actually still JSON) and perform the requested action (such as running malicious code).

Patches

A patch for this vulnerability has been released in the following Argo CD versions:

2.10-rc2 2.9.4 2.8.8 2.7.16

🚨 The patch contains a breaking API change. 🚨 The Argo CD API will no longer accept non-GET requests which do not specify application/json as their Content-Type. The accepted content types list is configurable, and it is possible (but discouraged) to disable the content type check completely.

Workarounds

The only way to completely resolve the issue is to upgrade.

Credits

The Argo CD team would like to express their gratitude to An Trinh of Calif who reported the issue confidentially according to our guidelines and published a helpful blog post to describe the issue. We would also like to thank them for actively participating in the review for the patch.

References

The problem was originally reported in a GitHub issue

1 / 3
Source: GitHub
First published (updated )
Severity
7.7
Path Traversal, Infoleak
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Impact

All versions of Argo CD are vulnerable to a path traversal bug that allows to pass arbitrary values files to be consumed by Helm charts.

Additionally, it is possible to craft special Helm chart packages containing value files that are actually symbolic links, pointing to arbitrary files outside the repository's root directory.

If an attacker with permissions to create or update Applications knows or can guess the full path to a file containing valid YAML, they can create a malicious Helm chart to consume that YAML as values files, thereby gaining access to data they would otherwise have no access to.

The impact can especially become critical in environments that make use of encrypted value files (e.g. using plugins with git-crypt or SOPS) containing sensitive or confidential data, and decrypt these secrets to disk before rendering the Helm chart.

Also, because any error message from helm template is passed back to the user, and these error messages are quite verbose, enumeration of files on the repository server's file system is possible.

Patches

A patch for this vulnerability has been released in the following Argo CD versions:

v2.3.0 v2.2.4 v2.1.9

We urge users of Argo CD to update their installation to one of the fixed versions as listed above.

Workarounds

No workaround for this issue.

References

https://apiiro.com/blog/malicious-kubernetes-helm-charts-can-be-used-to-steal-sensitive-information-from-argo-cd-deployments https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24348

For more information

Open an issue in the Argo CD issue tracker or discussions Join us on Slack in channel #argo-cd

Credits

The path traversal vulnerability was discovered and reported by Moshe Zioni, VP Security Research, Apiiro.

During the development of a fix for the path traversal vulnerability, the Argo CD team discovered the related issue with symbolic links.

The Argo CD team would like to thank Moshe Zioni for the responsible disclosure, and the constructive discussions during handling this issue!

1 / 2
Source: GitHub
First published (updated )
Severity
4.3
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

An access control issue in Argo CD v2.4.12 and below allows unauthenticated attackers to enumerate existing applications.

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203