CVE-2024-22424: CWE-352: Cross-Site Request Forgery (CSRF) in argoproj argo-cd

Severity: highType: vulnerabilityCVE-2024-22424

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. The Argo CD API prior to versions 2.10-rc2, 2.9.4, 2.8.8, and 2.7.15 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. 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). A patch for this vulnerability has been released in the following Argo CD versions: 2.10-rc2, 2.9.4, 2.8.8, and 2.7.15. 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. Users are advised to upgrade. There are no known workarounds for this vulnerability.

AI Analysis

Technical Summary

CVE-2024-22424 is a high-severity Cross-Site Request Forgery (CSRF) vulnerability affecting Argo CD, a popular GitOps continuous delivery tool for Kubernetes. The vulnerability exists in Argo CD API versions prior to 2.10-rc2, 2.9.4, 2.8.8, and 2.7.15. It allows an attacker who can inject malicious HTML content on a page within the same parent domain as Argo CD to trick authenticated users into executing unauthorized API requests. Argo CD uses a “Lax” SameSite cookie policy to prevent CSRF attacks from external domains by blocking the browser from sending authentication cookies with cross-site requests. However, when Argo CD is hosted on an internal subdomain, an attacker controlling a sibling subdomain (e.g., test.internal.example.com) can bypass this protection because the browser sends cookies to the parent domain, enabling CSRF attacks. Normally, browsers enforce Cross-Origin Resource Sharing (CORS) policies and send preflight OPTIONS requests for POST requests with sensitive content types like application/json. Argo CD previously did not validate the Content-Type header, allowing attackers to use a non-sensitive content type such as text/plain to bypass the preflight check. The API would then accept the request body (still JSON) and execute the malicious action, such as creating applications running malicious code. The patch released in the fixed versions enforces that non-GET requests must specify application/json as the Content-Type header, preventing this bypass. This patch introduces a breaking API change, but the content type validation can be configured or disabled (though disabling is discouraged). No known workarounds exist, and upgrading to the patched versions is strongly recommended. The CVSS v3.1 score is 8.4 (High), reflecting the network attack vector, high impact on confidentiality, integrity, and availability, and the requirement for user interaction but no privileges.

Potential Impact

For European organizations using Argo CD for Kubernetes continuous delivery, this vulnerability poses significant risks. Successful exploitation could allow attackers to create or modify Kubernetes applications, potentially deploying malicious code or altering deployment configurations. This compromises the confidentiality and integrity of the software supply chain and can lead to widespread service disruption or data breaches. Given that Argo CD is often deployed internally on subdomains, attackers who gain the ability to inject malicious HTML into related internal web pages or intranet portals could exploit this flaw. This risk is heightened in environments with complex domain structures or shared hosting environments. The attack requires tricking authenticated users to visit malicious pages, which could be achieved via phishing or compromised internal sites. The potential for supply chain compromise and unauthorized code execution makes this vulnerability particularly dangerous for critical infrastructure, financial institutions, and enterprises relying on Kubernetes for production workloads in Europe.

Mitigation Recommendations

1. Immediate upgrade to Argo CD versions 2.10-rc2, 2.9.4, 2.8.8, or 2.7.15 or later to apply the patch that enforces strict Content-Type validation on API requests. 2. Audit internal web applications and portals hosted on sibling or parent domains to ensure they cannot be used to inject malicious HTML or scripts that could trigger CSRF attacks. 3. Implement strict Content Security Policy (CSP) headers on internal web applications to reduce the risk of malicious script injection. 4. Restrict access to Argo CD API endpoints to trusted networks and users, minimizing exposure. 5. Monitor Argo CD API logs for unusual or unauthorized API calls that could indicate exploitation attempts. 6. Educate users about phishing risks and the dangers of clicking on untrusted links, especially within internal domains. 7. Consider network segmentation to isolate Argo CD instances and related internal web services to reduce the attack surface. 8. Review and tighten cookie policies and domain configurations to prevent cookie sharing across subdomains where possible. 9. Regularly review and update Kubernetes and GitOps security best practices to detect and prevent supply chain attacks.