cve-2024-22424
Vulnerability from cvelistv5
Published
2024-01-19 00:25
Modified
2024-08-01 22:43
Severity ?
8.3 (High) - CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H
Summary
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.
References
security-advisories@github.comhttps://github.com/argoproj/argo-cd/issues/2496Exploit, Issue Tracking, Third Party Advisory
security-advisories@github.comhttps://github.com/argoproj/argo-cd/pull/16860Patch
security-advisories@github.comhttps://github.com/argoproj/argo-cd/security/advisories/GHSA-92mw-q256-5vwgVendor Advisory
af854a3a-2127-422b-91ae-364da2661108https://github.com/argoproj/argo-cd/issues/2496Exploit, Issue Tracking, Third Party Advisory
af854a3a-2127-422b-91ae-364da2661108https://github.com/argoproj/argo-cd/pull/16860Patch
af854a3a-2127-422b-91ae-364da2661108https://github.com/argoproj/argo-cd/security/advisories/GHSA-92mw-q256-5vwgVendor Advisory
Impacted products
Vendor Product Version
argoproj argo-cd Version: >= 0.1.0, < 2.7.15
Version: >= 2.8.0, < 2.8.8
Version: >= 2.9.0, < 2.9.4
Version: >= 2.10.0-rc1, < 2.10-rc2
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
   containers: {
      adp: [
         {
            providerMetadata: {
               dateUpdated: "2024-08-01T22:43:34.945Z",
               orgId: "af854a3a-2127-422b-91ae-364da2661108",
               shortName: "CVE",
            },
            references: [
               {
                  name: "https://github.com/argoproj/argo-cd/security/advisories/GHSA-92mw-q256-5vwg",
                  tags: [
                     "x_refsource_CONFIRM",
                     "x_transferred",
                  ],
                  url: "https://github.com/argoproj/argo-cd/security/advisories/GHSA-92mw-q256-5vwg",
               },
               {
                  name: "https://github.com/argoproj/argo-cd/issues/2496",
                  tags: [
                     "x_refsource_MISC",
                     "x_transferred",
                  ],
                  url: "https://github.com/argoproj/argo-cd/issues/2496",
               },
               {
                  name: "https://github.com/argoproj/argo-cd/pull/16860",
                  tags: [
                     "x_refsource_MISC",
                     "x_transferred",
                  ],
                  url: "https://github.com/argoproj/argo-cd/pull/16860",
               },
            ],
            title: "CVE Program Container",
         },
      ],
      cna: {
         affected: [
            {
               product: "argo-cd",
               vendor: "argoproj",
               versions: [
                  {
                     status: "affected",
                     version: ">= 0.1.0, < 2.7.15",
                  },
                  {
                     status: "affected",
                     version: ">= 2.8.0, < 2.8.8",
                  },
                  {
                     status: "affected",
                     version: ">= 2.9.0, < 2.9.4",
                  },
                  {
                     status: "affected",
                     version: ">= 2.10.0-rc1, < 2.10-rc2",
                  },
               ],
            },
         ],
         descriptions: [
            {
               lang: "en",
               value: "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.",
            },
         ],
         metrics: [
            {
               cvssV3_1: {
                  attackComplexity: "HIGH",
                  attackVector: "NETWORK",
                  availabilityImpact: "HIGH",
                  baseScore: 8.4,
                  baseSeverity: "HIGH",
                  confidentialityImpact: "HIGH",
                  integrityImpact: "HIGH",
                  privilegesRequired: "NONE",
                  scope: "CHANGED",
                  userInteraction: "REQUIRED",
                  vectorString: "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
                  version: "3.1",
               },
            },
         ],
         problemTypes: [
            {
               descriptions: [
                  {
                     cweId: "CWE-352",
                     description: "CWE-352: Cross-Site Request Forgery (CSRF)",
                     lang: "en",
                     type: "CWE",
                  },
               ],
            },
         ],
         providerMetadata: {
            dateUpdated: "2024-01-19T00:25:44.946Z",
            orgId: "a0819718-46f1-4df5-94e2-005712e83aaa",
            shortName: "GitHub_M",
         },
         references: [
            {
               name: "https://github.com/argoproj/argo-cd/security/advisories/GHSA-92mw-q256-5vwg",
               tags: [
                  "x_refsource_CONFIRM",
               ],
               url: "https://github.com/argoproj/argo-cd/security/advisories/GHSA-92mw-q256-5vwg",
            },
            {
               name: "https://github.com/argoproj/argo-cd/issues/2496",
               tags: [
                  "x_refsource_MISC",
               ],
               url: "https://github.com/argoproj/argo-cd/issues/2496",
            },
            {
               name: "https://github.com/argoproj/argo-cd/pull/16860",
               tags: [
                  "x_refsource_MISC",
               ],
               url: "https://github.com/argoproj/argo-cd/pull/16860",
            },
         ],
         source: {
            advisory: "GHSA-92mw-q256-5vwg",
            discovery: "UNKNOWN",
         },
         title: "Cross-Site Request Forgery (CSRF) in github.com/argoproj/argo-cd",
      },
   },
   cveMetadata: {
      assignerOrgId: "a0819718-46f1-4df5-94e2-005712e83aaa",
      assignerShortName: "GitHub_M",
      cveId: "CVE-2024-22424",
      datePublished: "2024-01-19T00:25:44.946Z",
      dateReserved: "2024-01-10T15:09:55.556Z",
      dateUpdated: "2024-08-01T22:43:34.945Z",
      state: "PUBLISHED",
   },
   dataType: "CVE_RECORD",
   dataVersion: "5.1",
   "vulnerability-lookup:meta": {
      nvd: "{\"cve\":{\"id\":\"CVE-2024-22424\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2024-01-19T01:15:09.317\",\"lastModified\":\"2024-11-21T08:56:15.780\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"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.\"},{\"lang\":\"es\",\"value\":\"Argo CD es una herramienta declarativa de entrega continua de GitOps para Kubernetes. La API de Argo CD anterior a las versiones 2.10-rc2, 2.9.4, 2.8.8 y 2.7.15 es vulnerable a un ataque de cross-server request forgery (CSRF) cuando el atacante tiene la capacidad de escribir HTML en una página del mismo dominio principal que Argo CD. Un ataque CSRF funciona engañando a un usuario autenticado de Argo CD para que cargue una página web que contiene código para llamar a los endpoints de la API de Argo CD en nombre de la víctima. Por ejemplo, un atacante podría enviar a un usuario de Argo CD un enlace a una página que parece inofensiva pero que en segundo plano llama a un endpoint de la API de Argo CD para crear una aplicación que ejecute código malicioso. Argo CD utiliza la política de cookies \\\"Lax\\\" de SameSite para evitar ataques CSRF en los que el atacante controla un dominio externo. El sitio web externo malicioso puede intentar llamar a la API de Argo CD, pero el navegador web se negará a enviar el token de autenticación de Argo CD con la solicitud. Muchas empresas alojan Argo CD en un subdominio interno. Si un atacante puede colocar código malicioso, por ejemplo, en https://test.internal.example.com/, aún puede realizar un ataque CSRF. En este caso, la cookie SameSite \\\"Lax\\\" no impide que el navegador envíe la cookie de autenticación, porque el destino es un dominio principal de la API de Argo CD. Los navegadores generalmente bloquean este tipo de ataques aplicando políticas CORS a solicitudes confidenciales con tipos de contenido confidenciales. Específicamente, los navegadores enviarán una \\\"solicitud de verificación previa\\\" para POST con tipo de contenido \\\"application/json\\\" preguntando a la API de destino \\\"¿puede aceptar solicitudes de mi dominio?\\\" Si la API de destino no responde \\\"sí\\\", el navegador bloqueará la solicitud. Antes de las versiones parcheadas, Argo CD no validaba que las solicitudes incluyeran el encabezado del tipo de contenido correcto. Por lo tanto, un atacante podría eludir la verificación CORS del navegador configurando el tipo de contenido en algo que se considere \\\"no sensible\\\", como \\\"texto/plano\\\". El navegador no enviaría la solicitud de verificación previa y Argo CD aceptaría felizmente el contenido (que en realidad sigue siendo JSON) y realizaría la acción solicitada (como ejecutar código malicioso). Se lanzó un parche para esta vulnerabilidad en las siguientes versiones de Argo CD: 2.10-rc2, 2.9.4, 2.8.8 y 2.7.15. El parche contiene un cambio importante en la API. La API de Argo CD ya no aceptará solicitudes que no sean GET y que no especifiquen application/json como tipo de contenido. La lista de tipos de contenido aceptados es configurable y es posible (pero desaconsejado) desactivar completamente la verificación del tipo de contenido. Se recomienda a los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H\",\"baseScore\":8.3,\"baseSeverity\":\"HIGH\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"REQUIRED\",\"scope\":\"CHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.6,\"impactScore\":6.0},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H\",\"baseScore\":8.3,\"baseSeverity\":\"HIGH\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"REQUIRED\",\"scope\":\"CHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.6,\"impactScore\":6.0}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-352\"}]},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-352\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:argoproj:argo_cd:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"2.8.0\",\"versionEndExcluding\":\"2.8.8\",\"matchCriteriaId\":\"8CED13D7-50A9-4645-9D05-29C9F0DE1968\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:argoproj:argo_cd:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"2.9.0\",\"versionEndExcluding\":\"2.9.4\",\"matchCriteriaId\":\"7A322D38-37A6-428D-8D7D-C11BAD24EFAD\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:argoproj:argo_cd:2.10.0:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"0E94165C-F60B-469B-8D6D-14E310013B75\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:linuxfoundation:argo-cd:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"0.1.0\",\"versionEndExcluding\":\"2.7.16\",\"matchCriteriaId\":\"D7E1C1DF-F7F5-472D-A429-797D45E1492D\"}]}]}],\"references\":[{\"url\":\"https://github.com/argoproj/argo-cd/issues/2496\",\"source\":\"security-advisories@github.com\",\"tags\":[\"Exploit\",\"Issue Tracking\",\"Third Party Advisory\"]},{\"url\":\"https://github.com/argoproj/argo-cd/pull/16860\",\"source\":\"security-advisories@github.com\",\"tags\":[\"Patch\"]},{\"url\":\"https://github.com/argoproj/argo-cd/security/advisories/GHSA-92mw-q256-5vwg\",\"source\":\"security-advisories@github.com\",\"tags\":[\"Vendor Advisory\"]},{\"url\":\"https://github.com/argoproj/argo-cd/issues/2496\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Exploit\",\"Issue Tracking\",\"Third Party Advisory\"]},{\"url\":\"https://github.com/argoproj/argo-cd/pull/16860\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://github.com/argoproj/argo-cd/security/advisories/GHSA-92mw-q256-5vwg\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Vendor Advisory\"]}]}}",
   },
}


Log in or create an account to share your comment.

Security Advisory comment format.

This schema specifies the format of a comment related to a security advisory.

UUIDv4 of the comment
UUIDv4 of the Vulnerability-Lookup instance
When the comment was created originally
When the comment was last updated
Title of the comment
Description of the comment
The identifier of the vulnerability (CVE ID, GHSA-ID, PYSEC ID, etc.).



Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.