Argo CD is a declarative continuous deployment for Kubernetes. All versions of ArgoCD starting from v2.4 have a bug where the ArgoCD repo-server component is vulnerable to a Denial-of-Service attack vector. Specifically, the said component extracts a user-controlled tar.gz file without validating the size of its inner files. As a result, a malicious, low-privileged user can send a malicious tar.gz file that exploits this vulnerability to the repo-server, thereby harming the systems functionality and availability. Additionally, the repo-server is susceptible to another vulnerability due to the fact that it does not check the extracted file permissions before attempting to delete them. Consequently, an attacker can craft a malicious tar.gz archive in a way that prevents the deletion of its inner files when the manifest generation process is completed. A patch for this vulnerability has been released in versions 2.6.15, 2.7.14, and 2.8.3. Users are advised to upgrade. The only way to completely resolve the issue is to upgrade, however users unable to upgrade should configure RBAC (Role-Based Access Control) and provide access for configuring applications only to a limited number of administrators. These administrators should utilize trusted and verified Helm charts.
The product does not properly control the allocation and maintenance of a limited resource.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Argo_cd | Argoproj | 2.4.0 (including) | 2.6.15 (excluding) |
| Argo_cd | Argoproj | 2.7.0 (including) | 2.7.14 (excluding) |
| Argo_cd | Argoproj | 2.8.0 (including) | 2.8.3 (excluding) |
| Red Hat OpenShift GitOps 1.8 | RedHat | openshift-gitops-1/argocd-rhel8:v1.8.5-1 | * |
| Red Hat OpenShift GitOps 1.9 | RedHat | openshift-gitops-1/argocd-rhel8:v1.9.2-2 | * |
Mitigation of resource exhaustion attacks requires that the target system either:
The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
The second solution is simply difficult to effectively institute – and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.