Alexmt

**Name of the Vulnerable Software and Affected Versions** Argo CD versions prior to 2.6.15 Argo CD versions prior to 2.7.14 Argo CD versions prior to 2.8.3 **Description** Argo CD is a declarative continuous deployment for Kubernetes. Argo CD Cluster secrets might be managed declaratively using Argo CD / kubectl apply, resulting in the full secret body being stored in the `kubectl.kubernetes.io/last-applied-configuration` annotation. This exposes the annotation, which includes the full secret body, when managing cluster labels and annotations. To view cluster annotations via the Argo CD API, a user must have `clusters, get` RBAC access. In many cases, cluster secrets do not contain sensitive information, but sometimes, as in bearer-token auth, the contents might be very sensitive. **Recommendations** For versions prior to 2.6.15, upgrade to version 2.6.15 or later. For versions prior to 2.7.14, upgrade to version 2.7.14 or later. For versions prior to 2.8.3, upgrade to version 2.8.3 or later. As a temporary workaround, update/deploy cluster secret with the `server-side-apply` flag, which does not use or rely on the `kubectl.kubernetes.io/last-applied-configuration` annotation. Note that annotations for existing secrets will require manual removal.

**Name of the Vulnerable Software and Affected Versions** Argo CD versions 0.5.0 through 2.3.1 Argo CD versions 2.0.x and earlier **Description** Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. All unpatched versions of Argo CD starting with 1.0.0 are vulnerable to an improper access control bug, allowing a malicious user to potentially escalate their privileges to admin-level. To perform exploits, an authorized Argo CD user must have push access to an Application's source git or Helm repository or `sync` and `override` access to an Application. Once a user has that access, different exploitation levels are possible depending on their other RBAC privileges. **Recommendations** For Argo CD versions 2.3.1 and earlier, upgrade to version 2.3.2. For Argo CD versions 2.2.x, upgrade to version 2.2.8. For Argo CD versions 2.1.x, upgrade to version 2.1.14. As a temporary workaround, consider limiting who has push access to Application source repositories or `sync` + `override` access to Applications, and limit which repositories are available in projects where users have `update` access to Applications. Restrict access to the `delete`, `get`, or `action` access to Applications to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Argo CD versions 1.5.0 through 2.1.10 Argo CD versions 2.2.0 through 2.2.5 Argo CD versions 2.3.0 and earlier, excluding 2.3.0 **Description** A path traversal vulnerability in Argo CD allows a malicious user with read/write access to leak sensitive files from Argo CD's repo-server. A malicious Argo CD user who has been granted `create` or `update` access to Applications can leak the contents of any text file on the repo-server. By crafting a malicious Helm chart and using it in an Application, the attacker can retrieve the sensitive file's contents either as part of the generated manifests or in an error message. The attacker would have to know or guess the location of the target file. Sensitive files which could be leaked include files from another Application's source repositories or any secrets which have been mounted as files on the repo-server. **Recommendations** For Argo CD versions 1.5.0 through 2.1.10, update to version 2.1.11 or later. For Argo CD versions 2.2.0 through 2.2.5, update to version 2.2.6 or later. For Argo CD versions prior to 2.3.0, update to version 2.3.0 or later. As a temporary workaround, consider avoiding storing secrets in git, avoiding mounting secrets as files on the repo-server, avoiding decrypting secrets into files on the repo-server, and carefully limiting who can `create` or `update` Applications.

**Name of the Vulnerable Software and Affected Versions** Argo CD versions 1.3.0 through 2.1.10 Argo CD versions 2.2.0 through 2.2.5 Argo CD versions 2.3.0 and earlier, excluding 2.3.0 itself as it is a fixed version **Description** The issue is related to a path traversal bug compounded by an improper access control bug in Argo CD, allowing a malicious user with read-only repository access to leak sensitive files from Argo CD's repo-server. A malicious Argo CD user who has been granted `get` access for a repository containing a Helm chart can craft an API request to the "/api/v1/repositories/{repo url}/appdetails" endpoint to leak the contents of out-of-bounds files from the repo-server. The malicious payload would reference an out-of-bounds file, and the contents of that file would be returned as part of the response. Sensitive files which could be leaked include files from other Applications' source repositories or any secrets which have been mounted as files on the repo-server. **Recommendations** For Argo CD versions 1.3.0 through 2.1.10, update to version 2.1.11 or later. For Argo CD versions 2.2.0 through 2.2.5, update to version 2.2.6 or later. For Argo CD versions prior to 2.3.0, update to version 2.3.0 or later. As a temporary workaround, consider avoiding storing secrets in git, avoiding mounting secrets as files on the repo-server, avoiding decrypting secrets into files on the repo-server, and carefully limiting who has `get` access for repositories.

**Name of the Vulnerable Software and Affected Versions** Argo CD versions 1.0.0 and earlier Argo CD versions 0.8.0 through 0.9.x Argo CD versions 0.5.0 through 0.7.x **Description** The issue is related to an improper access control bug in Argo CD, allowing a malicious user to potentially escalate their privileges to admin-level. This can be achieved if the user has push access to an Application's source git or Helm repository or `sync` and `override` access to an Application. The exploitation levels vary depending on the user's other RBAC privileges, including `update`, `delete`, `get`, and `action` access to Applications. A related exploit is possible for a user with `get` access to an Application, allowing them to access any Event in the Application's destination cluster if they know the involved object's name, UID, and namespace. **Recommendations** For versions 2.0.x and earlier, upgrade to a newer version, such as v2.3.2, v2.2.8, or v2.1.14, by following the upgrade instructions in the changelog. For argo-helm chart users deploying v2.3.x, upgrade the chart to version 4.2.2. For Argo CD 2.2 and 2.1 users, set the `global.image.tag` value to the latest in the current release series (v2.2.8 or v2.1.14). As a temporary workaround, consider limiting who has push access to Application source repositories or `sync` and `override` access to Applications, and limiting which repositories are available in projects where users have `update` access to Applications. Limit who has `delete`, `get`, or `action` access to Applications to avoid unauthorized resource inspection/tampering.