Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
23 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/argoproj/argo-cd/v2 >= 2.9.0-rc1, <= 2.14.19
Fixed in
2.14.20· Vendor fix available
Issue
In the default configuration, webhook.azuredevops.username and webhook.azuredevops.password not set, Argo CD’s /api/webhook endpoint crashes the entire argocd-server process when it receives an Azure DevOps Push event whose JSON array resource.refUpdates is empty. The slice index [0] is accessed without a length check, causing an index-out-of-range panic. A single unauthenticated HTTP POST is enough to kill the process. Details If the attacker supplies "refUpdates": [], the slice has length 0. The webhook code has no recover(), so the panic terminates the entire binary. PoC payload-azure-empty.json: curl call: Observed crash: Mitigation If you use Azure DevOps and need to handle webhook events, configure a webhook secret to ensure only trusted parties can invoke the webhook handler. If you do not use Azure DevOps, you can set the webhook secrets to long, random values to effectively disable webhook handling for Azure DevOps payloads. For more information Open an issue in the…
Recommended action: Upgrade to 2.14.20 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-cd/v2 >= 2.1.0, <= 2.14.19
Fixed in
2.14.20· Vendor fix available
Issue
A race condition in the repository credentials handler can cause the Argo CD server to panic and crash when concurrent operations are performed on the same repository URL. Details The vulnerability is located in numerous repository related handlers in the util/db/repositorysecrets.go file. For example, in the secretToRepoCred function. The issue manifests as a concurrent map access panic: The race condition occurs due to: 1. Concurrent repository credential operations (create/update/delete) accessing the same map 2. Kubernetes informer re-syncs happening simultaneously 3. Background watchers updating the same secret data 4. No mutex protection for map access A valid API token with repositories resource permissions (create, update, or delete actions) is required to trigger the race condition. Impact This vulnerability causes the entire Argo CD server to crash and become unavailable. Attackers can repeatedly and continuously trigger the race condition to maintain a…
Recommended action: Upgrade to 2.14.20 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-cd/v2 >= 2.13.0, < 2.13.9; >= 2.14.0, < 2.14.16
Fixed in
2.13.92.14.16· Vendor fix available
Issue
Argo CD API tokens with project-level permissions are able to retrieve sensitive repository credentials (usernames, passwords) through the project details API endpoint, even when the token only has standard application management permissions and no explicit access to secrets. Component: Project API (/api/v1/projects/{project}/detailed) Vulnerability Details Expected Behavior API tokens should require explicit permission to access sensitive credential information. Standard project permissions should not grant access to repository secrets. Actual Behavior API tokens with basic project permissions can retrieve all repository credentials associated with a project through the detailed project API endpoint. Note: This vulnerability does not only affect project-level permissions. Any token with project get permissions is also vulnerable, including global permissions such as: p, role/user, projects, get, , allow Steps to Reproduce 1. Create an API token with the following…
Recommended action: Upgrade to 2.14.16 or 2.13.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Argo CD v2.11.3 and before, discovering that even if the user's permissions are revoked, the user can still send any Websocket message, which allows the user to view sensitive information. Even though they shouldn't have such access. Description Argo CD has a Web-based terminal that allows you to get a shell inside a running pod, just like you would with kubectl exec. However, when the administrator enables this function and grants permission to the user , even if the user revokes this permission, the user can still perform operations in the container, as long as the user keeps the terminal view open for a long time. CVE-2023-40025 Although the token expiration and revocation of the user are fixed, however, the fix does not address the situation of revocation of only user permissions, which may still lead to the leakage of sensitive information. Patches A patch for this vulnerability has been released in the following Argo CD versions: v2.11.7 v2.10.16 v2.9.21 For more information If…
Recommended action: Upgrade to 2.11.7, 2.10.16 or 2.9.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact DoS vuln via OOM using jq in ignoreDifferences. Patches A patch for this vulnerability has been released in the following Argo CD versions: v2.10.8 v2.9.13 v2.8.17 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 @crenshaw-dev (Michael Crenshaw) The Argo team would like to thank these contributors for their responsible disclosure and constructive communications during the resolve of this issue
Recommended action: Upgrade to 2.10.8, 2.9.13 or 2.8.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact I can convince the UI to let me do things with an invalid Application. 1. Admin gives me p, michael, applications, , demo/, allow, where demo can just deploy to the demo namespace 2. Admin gives me AppProject dev which reconciles from ns dev-apps 3. Admin gives me p, michael, applications, sync, dev/, allow, i.e. no updating via the UI allowed, gitops-only 4. I create an Application called pwn in dev-apps with project dev and sync the app with sources from git 5. I change the Application’s project to demo via kubectl or gitops (whichever mechanism my admins have given me, because it should be safe) 6. I use the UI to edit the resource which should only be mutable via gitops Patches A patch for this vulnerability has been released in the following Argo CD versions: v2.10.7 v2.9.12 v2.8.16 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…
Recommended action: Upgrade to 2.10.7, 2.9.12 or 2.8.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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, it's possible to crash the repo server component through an out of memory error by pointing it to a malicious Helm registry. The loadRepoIndex() function in the ArgoCD's helm package, does not limit the size nor time while fetching the data. It fetches it and creates a byte slice from the retrieved data in one go. If the registry is implemented to push data continuously, the repo server will keep allocating memory until it runs out of it. Patches A patch for this vulnerability has been released in the following Argo CD versions: v2.10.5 v2.9.10 v2.8.14 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 Jakub Ciolek The Argo team would like to thank…
Recommended action: Upgrade to 2.10.5, 2.9.10 or 2.8.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An attacker can effectively bypass the rate limit and brute force protections by exploiting the application's weak cache-based mechanism. This loophole in security can be combined with other vulnerabilities to attack the default admin account. This flaw undermines a previously patched CVE intended to protect against brute-force attacks. Details The application's brute force protection relies on a cache mechanism that tracks login attempts for each user. This cache is limited to a defaultMaxCacheSize of 1000 entries. An attacker can overflow this cache by bombarding it with login attempts for different users, thereby pushing out the admin account's failed attempts and effectively resetting the rate limit for that account. The brute force protection mechanism's code: PoC 1. Set up the application environment and identify the login page. 2. Execute 4 failed login attempts for the admin account. 3. Run a Burp Intruder attack to populate the cache with login attempts for usernames…
Recommended action: Upgrade to 2.10.4, 2.9.9 or 2.8.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An attacker can exploit a chain of vulnerabilities, including a Denial of Service (DoS) flaw and in-memory data storage weakness, to effectively bypass the application's brute force login protection. This makes the application susceptible to brute force attacks, compromising the security of all user accounts. Details The issue arises from two main vulnerabilities: 1. The application crashes due to a previously described DoS vulnerability caused by unsafe array modifications in a multi-threaded environment. 2. The application saves the data of failed login attempts in-memory, without persistent storage. When the application crashes and restarts, this data is lost, resetting the brute force protections. By chaining these vulnerabilities, an attacker can circumvent the limitations placed on the number of login attempts. PoC 1. Run the provided PoC script. 2. Observe that the script makes 6 login attempts, one more than the set limit of 5 failed attempts. 3. This is made possible…
Recommended action: Upgrade to 2.10.4, 2.9.9 or 2.8.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.…
Recommended action: Upgrade to 2.8.3, 2.7.14 or 2.6.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.8.3, 2.7.14 or 2.6.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
2.0.0-20230821201509-e047efa8f9512.8.12.6.142.7.12· Vendor fix available
Issue
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…
Recommended action: Upgrade to 2.8.1, 2.7.12, 2.6.14 or 2.0.0-20230821201509-e047efa8f951 (pre-release) by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-cd/v2 >= 2.6.0-rc1, < 2.6.1
Fixed in
2.6.1· Vendor fix available
Issue
Impact All versions of Argo CD starting with v2.6.0-rc1 have an output sanitization bug which leaks repository access credentials in error messages. These error messages are visible to the user, and they are logged. The error message is visible when a user attempts to create or update an Application via the Argo CD API (and therefor the UI or CLI). The user must have applications, create or applications, update RBAC access to reach the code which may produce the error. The user is not guaranteed to be able to trigger the error message. They may attempt to spam the API with requests to trigger a rate limit error from the upstream repository. If the user has repositories, update access, they may edit an existing repository to introduce a URL typo or otherwise force an error message. But if they have that level of access, they are probably intended to have access to the credentials anyway. Patches A patch for this vulnerability has been released in the following Argo CD version: v2.6.1…
Recommended action: Upgrade to 2.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-cd/v2 >= 2.5.0-rc1, < 2.5.8; >= 2.6.0-rc4, <= 2.6.0-rc4
Fixed in
2.5.82.6.0-rc5· Vendor fix available
Issue
Impact All Argo CD versions starting with 2.5.0-rc1 are vulnerable to an authorization bypass bug which allows a malicious Argo CD user to deploy Applications outside the configured allowed namespaces. Description of exploit Reconciled Application namespaces are specified as a comma-delimited list of glob patterns. When sharding is enabled on the Application controller, it does not enforce that list of patterns when reconciling Applications. For example, if Application namespaces are configured to be argocd-, the Application controller may reconcile an Application installed in a namespace called other, even though it does not start with argocd-. Reconciliation of the out-of-bounds Application is only triggered when the Application is updated, so the attacker must be able to cause an update operation on the Application resource. Limitations This bug only applies to users who have explicitly enabled the "apps-in-any-namespace" feature by setting application.namespaces in the…
Recommended action: Upgrade to 2.6.0-rc5 (pre-release) or 2.5.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact All versions of Argo CD starting with v0.7.0 are vulnerable to an uncontrolled memory consumption bug, allowing an authorized malicious user to crash the repo-server service. The repo-server is a critical component of Argo CD, so crashing the repo-server effectively denies core Argo CD services (such as syncing Application updates). To achieve denial of service, the attacker must be an authenticated Argo CD user authorized to deploy Applications from a repository which contains (or can be made to contain) a large file. Patches A patch for this vulnerability has been released in the following Argo CD versions: v2.4.1 v2.3.5 v2.2.10 v2.1.16 The patch introduces a new reposerver.max.combined.directory.manifests.size config parameter, which you should tune before upgrading in production. It caps the maximum total file size of .yaml/.yml/.json files in directory-type (raw manifest) Applications. The default max is 10M per Application. This max is designed to keep any single app…
Recommended action: Upgrade to 2.4.1, 2.3.5, 2.2.10 or 2.1.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact All unpatched versions of Argo CD starting with v1.3.0 are vulnerable to a symlink following bug allowing a malicious user with repository write access to leak sensitive YAML files from Argo CD's repo-server. A malicious Argo CD user with write access for a repository which is (or may be) used in a Helm-type Application may commit a symlink which points to an out-of-bounds file. If the target file is a valid YAML file, the attacker can read the contents of that file. Sensitive files which could be leaked include manifest files from other Applications' source repositories (potentially decrypted files, if you are using a decryption plugin) or any YAML-formatted secrets which have been mounted as files on the repo-server. Patches A patch for this vulnerability has been released in the following Argo CD versions: v2.4.1 v2.3.5 v2.2.10 v2.1.16 Workarounds If you are using =v2.3.0 and do not have any Helm-type Applications, disable the Helm config management tool. Mitigations Avoid…
Recommended action: Upgrade to 2.4.1, 2.3.5, 2.2.10 or 2.1.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact All unpatched versions of Argo CD starting with v1.0.0 are vulnerable to a cross-site scripting (XSS) bug allowing a malicious user to inject a javascript: link in the UI. When clicked by a victim user, the script will execute with the victim's permissions (up to and including admin). The script would be capable of doing anything which is possible in the UI or via the API, such as creating, modifying, and deleting Kubernetes resources. Patches A patch for this vulnerability has been released in the following Argo CD versions: v2.4.1 v2.3.5 v2.2.10 v2.1.16 Workarounds There are no completely-safe workarounds besides upgrading. Mitigations: 1. Avoid clicking external links presented in the UI. Here is an example of an Application node with an external link: The link's title is user-configurable. So even if you hover the link, and the tooltip looks safe, the link might be malicious. The only way to be certain that the link is safe is to inspect the page's source. 2. Carefully…
Recommended action: Upgrade to 2.4.1, 2.3.5, 2.2.10 or 2.1.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact All versions of Argo CD starting with v0.11.0 are vulnerable to a variety of attacks when an SSO login is initiated from the Argo CD CLI or UI. The vulnerabilities are due to the use of insufficiently random values in parameters in Oauth2/OIDC login flows. In each case, using a relatively-predictable (time-based) seed in a non-cryptographically-secure pseudo-random number generator made the parameter less random than required by the relevant spec or by general best practices. In some cases, using too short a value made the entropy even less sufficient. (The specific weak parameters are listed in the References section.) The attacks on login flows which are meant to be mitigated by these parameters are difficult to accomplish but can have a high impact (potentially granting an attacker admin access to Argo CD). The CVSS for this Security Advisory assumes the worst-case scenario. Patches A patch for this vulnerability has been released in the following Argo CD versions: v2.4.1…
Recommended action: Upgrade to 2.4.1, 2.3.5, 2.2.10 or 2.1.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A critical vulnerability has been discovered in Argo CD which would allow unauthenticated users to impersonate as any Argo CD user or role, including the admin user, by sending a specifically crafted JSON Web Token (JWT) along with the request. In order for this vulnerability to be exploited, anonymous access to the Argo CD instance must have been enabled. In a default Argo CD installation, anonymous access is disabled. To find out if anonymous access is enabled in your instance, please see the Workarounds section of this advisory below. The vulnerability can be exploited to impersonate as any user or role, including the built-in admin account regardless of whether that account is enabled or disabled. Also, the attacker does not need an account on the Argo CD instance in order to exploit this. If anonymous access to the instance is enabled, an attacker can: Escalate their privileges, effectively allowing them to gain the same privileges on the cluster as the Argo CD instance,…
Recommended action: Upgrade to 2.3.4, 2.2.9 or 2.1.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A vulnerability was found in Argo CD that allows an attacker to spoof error messages on the login screen when SSO is enabled. In order to exploit this vulnerability, an attacker would have to trick the victim to visit a specially crafted URL which contains the message to be displayed. As far as the research of the Argo CD team concluded, it is not possible to specify any active content (e.g. Javascript) or other HTML fragments (e.g. clickable links) in the spoofed message. Patched versions A patch for this vulnerability has been released in the following Argo CD versions: v2.3.4 v2.2.9 v2.1.15 Workarounds No workaround available. Mitigations It is advised to update to an Argo CD version containing a fix for this issue (see Patched versions above). Credits This vulnerability was discovered by Naufal Septiadi (<naufal@horangi.com) and reported to us in a responsible way. For more information <!-- Use only one of the paragraphs below. Remove all others. -- <!-- For Argo CD --…
Recommended action: Upgrade to 2.3.4, 2.2.9 or 2.1.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact All unpatched versions of Argo CD starting with v0.7.0 are vulnerable to a symlink following bug allowing a malicious user with repository write access to leak sensitive files from Argo CD's repo-server. A malicious Argo CD user with write access for a repository which is (or may be) used in a directory-type Application may commit a symlink which points to an out-of-bounds file. If the target file is a valid JSON or YAML manifest file, and the resource is allowed in the Application, the attacker can read the contents of that manifest file. (In versions <2.3.2, <2.2.8, and <2.1.14, the attacker may read the files contents even if the resource is not allowed in the Application). If the target file is valid JSON but is not a manifest file, the attacker may read the contents of the file. If the target file is not valid JSON or YAML, the attacker may read partial file contents (usually just the first character of the file). Sensitive files which could be leaked include manifest…
Recommended action: Upgrade to 2.3.4, 2.2.9 or 2.1.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-cd/v2 < 2.1.9; >= 2.2.0, < 2.2.4
Fixed in
2.2.42.1.9· Vendor fix available
Issue
Impact All versions of Argo CD are vulnerable to a path traversal bug that allows to pass arbitrary values files to be consumed by Helm charts. Additionally, it is possible to craft special Helm chart packages containing value files that are actually symbolic links, pointing to arbitrary files outside the repository's root directory. If an attacker with permissions to create or update Applications knows or can guess the full path to a file containing valid YAML, they can create a malicious Helm chart to consume that YAML as values files, thereby gaining access to data they would otherwise have no access to. The impact can especially become critical in environments that make use of encrypted value files (e.g. using plugins with git-crypt or SOPS) containing sensitive or confidential data, and decrypt these secrets to disk before rendering the Helm chart. Also, because any error message from helm template is passed back to the user, and these error messages are quite verbose,…
Recommended action: Upgrade to 2.2.4 or 2.1.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-cd/v2 < 1.7.13; >= 1.8.0, < 1.8.6
Fixed in
1.8.61.7.13· Vendor fix available
Issue
Impact When using SSO with the Argo CD CLI, a malicious SSO provider could have sent specially crafted error message that would result in XSS on the client by means of executing arbitrary JavaScript code. We believe the exploitation of this vulnerability is only be possible when Argo CD is connected to a compromised/malicious SSO provider. Patches A patch for this vulnerability is available with the v1.8.7 and v1.7.14 releases of Argo CD. Workarounds Do not use SSO with the CLI when you don't trust your SSO provider 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 The issue was found during static code scanning with CodeQL and fixed by the Argo CD team. While we believed that a rogue SSO provider would pose a severe threat by itself, we fixed it like a regular bug. The Argo CD team would like to thank Adam Gold of Snyk (https://snyk.io) for stepping up and classifying this…
Recommended action: Upgrade to 1.8.6 or 1.7.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.