GHSA-92mw-q256-5vwg CVE-2024-22424
github.com/argoproj/argo-cd Cross-Site Request Forgery vulnerability
- Severity
- 8.3 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.48%
- Chance of exploitation in the next 30 days. Higher than 41.70% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-352 Cross-Site Request Forgery (CSRF)
- Fix
2.7.16- Upgrade github.com/argoproj/argo-cd/v2 to this version or later
Description
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
Affected versions
Go
| Package | Vulnerable | Fixed in |
|---|---|---|
| github.com/argoproj/argo-cd | >= 0.1.0, <= 1.8.7 |
No fix yet |
| github.com/argoproj/argo-cd/v2 | < 2.7.16 |
2.7.16 |
| github.com/argoproj/argo-cd/v2 | >= 2.8.0-rc1, < 2.8.8 |
2.8.8 |
| github.com/argoproj/argo-cd/v2 | >= 2.9.0-rc1, < 2.9.4 |
2.9.4 |
| github.com/argoproj/argo-cd/v2 | >= 2.10.0-rc1, < 2.10-rc2 |
2.10-rc2 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
github.com/argoproj/argo-cd/v2 Go → 2.7.16
- go
go get github.com/argoproj/argo-cd/v2@v2.7.16 && go mod tidy
Severity breakdown
CVSS 3.1 8.3
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- None
- User interaction
- Required
- Scope
- Changed
- Confidentiality
- High
- Integrity
- High
- Availability
- High
Weakness
CWE-352: Cross-Site Request Forgery (CSRF)
The web application does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent the request, which could have originated from an unauthorized actor.
How to prevent it
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, use anti-CSRF packages such as the OWASP CSRFGuard. [REF-330] Another example is the ESAPI Session Management control, which includes a component for CSRF. [REF-45]
- Implementation: Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script.
- Architecture and Design: Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form. Be sure that the nonce is not predictable (CWE-330). [REF-332]
- Architecture and Design: Identify especially dangerous operations. When the user performs a dangerous operation, send a separate confirmation request to ensure that the user intended to perform that operation.
- Architecture and Design: Use the "double-submitted cookie" method as described by Felten and Zeller: When a user visits a site, the site should generate a pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. Because of the same-origin policy, an attacker cannot read or modify the value stored in the cookie. To successfully submit a form on behalf of the user, the attacker would have to correctly guess the pseudorandom value. If the pseudorandom value is cryptographically strong, this will be prohibitively difficult. This technique requires Javascript, so it may not work for browsers that have Javascript disabled. [REF-331]
- Architecture and Design: Do not use the GET method for any request that triggers a state change.
- Implementation: Check the HTTP Referer header to see if the request originated from an expected page. This could break legitimate functionality, because users or proxies may have disabled sending the Referer for privacy reasons.
References
Advisories
Packages
Other links
- github.com/argoproj/argo-cd/security/advisories/GHSA-92mw-q256-5vwg
- github.com/argoproj/argo-cd/issues/2496
- github.com/argoproj/argo-cd/pull/16860
- github.com/argoproj/argo-cd/commit/0b459f224b3186707809be8240dfc3a6028f42a0
- github.com/argoproj/argo-cd/commit/13fe3ca589f6f2ded6001ce114e354602ed058b3
- github.com/argoproj/argo-cd/commit/3c5878ecf41581942281e9c95745f073bdfbf9c3
- github.com/argoproj/argo-cd/commit/f569aa105e0fe5940bc736c68e2fc90ee4a6ed94
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-fmxq-cgp8-87wp Argo CD: AppProject destination-namespace and resource restrictions bypassed by PreDelete/PostDelete resource hooks | Critical | Also affects github.com/argoproj/argo-cd |
| GHSA-j6cw-g6p4-7hch Argo CD repo-server command injection via crafted SSH repository SOCKS5 proxy URL | High | Also affects github.com/argoproj/argo-cd |
| GHSA-h98r-wv3h-fr38 Argo CD: Stored XSS in application link annotations enables developer-to-admin privilege escalation | High | Also affects github.com/argoproj/argo-cd |
| GO-2026-5618 Argo CD: Kubernetes Secret Extraction via ArgoCD ServerSideDiff via sensitive annotations | Medium | Also affects github.com/argoproj/argo-cd |
| GO-2026-5099 ArgoCD ServerSideDiff is vulnerable to Kubernetes Secret Extraction | Critical | Also affects github.com/argoproj/argo-cd |
| GHSA-gpx4-37g2-c8pv Argo CD Unauthenticated Remote DoS via malformed Azure DevOps git.push webhook | High | Also affects github.com/argoproj/argo-cd |
| GHSA-wp4p-9pxh-cgx2 argo-cd vulnerable unauthenticated DoS via malformed Gogs webhook payload | High | Also affects github.com/argoproj/argo-cd |
| GHSA-f9gq-prrc-hrhc Unauthenticated argocd-server panic via a malicious Bitbucket-Server webhook payload | High | Also affects github.com/argoproj/argo-cd |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor