Impact
Argo CD Cluster secrets might be managed declaratively using Argo CD / kubectl apply. As a result, the full secret body is stored inkubectl.kubernetes.io/last-applied-configuration annotation.
https://github.com/argoproj/argo-cd/pull/7139 introduced the ability to manage cluster labels and annotations. Since clusters are stored as secrets it also exposes the kubectl.kubernetes.io/last-applied-configuration annotation which includes full secret body. In order to view the cluster annotations via the Argo CD API, the user must have clusters, get RBAC access.
Note: In many cases, cluster secrets do not contain any actually-secret information. But sometimes, as in bearer-token auth, the contents might be very sensitive.
Patches
The bug has been patched in the following versions:
2.8.3 2.7.14 2.6.15
Workarounds
Update/Deploy cluster secret with server-side-apply flag which does not use or rely on kubectl.kubernetes.io/last-applied-configuration annotation. Note: annotation for existing secrets will require manual removal.
For more information
Open an issue in the Argo CD issue tracker or discussions Join us on Slack in channel #argo-cd
Impact All versions of Argo CD starting from v2.6.0 have a bug where open web terminal sessions do not expire. This bug allows users to send any websocket messages even if the token has already expired. The most straightforward scenario is when a user opens the terminal view and leaves it open for an extended period. This allows the user to view sensitive information even when they should have been logged out already.
Patches A patch for this vulnerability has been released in the following Argo CD version:
v2.6.14 v2.7.12 v2.8.1
Workarounds The only way to completely resolve the issue is to upgrade.
Mitigations Disable web-based terminal or define RBAC rules to it https://argo-cd.readthedocs.io/en/latest/operator-manual/webbasedterminal/
For more information If you have any questions or comments about this advisory: Open an issue in the Argo CD issue tracker or discussions Join us on Slack in channel #argo-cd
Credits
Thank you to bean.zhang (@zhlu32 ) of HIT-IDS ChunkL Team who discovered the issue and reported it confidentially according to our guidelines.
Impact 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 system's 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.
Patches A patch for this vulnerability has been released in the following Argo CD versions:
v2.6.15 v2.7.14 v2.8.3
Workarounds The only way to completely resolve the issue is to upgrade.
Mitigations 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.
For more information If you have any questions or comments about this advisory: Open an issue in the Argo CD issue tracker or discussions Join us on Slack in channel #argo-cd
Credits This vulnerability was found & reported by GE Vernova – Amit Laish.
The Argo team would like to thank these contributors for their responsible disclosure and constructive communications during the resolve of this issue