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
19 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact It’s possible for authenticated users to enumerate clusters by name by inspecting error messages: It’s also possible to enumerate the names of projects with project-scoped clusters if you know the names of the clusters. Patches A patch for this vulnerability has been released in the following Argo CD versions: v2.11.3 v2.10.12 v2.9.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.11.3, 2.10.12 or 2.9.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 All Argo CD versions starting with v2.3.0-rc1 are vulnerable to an improper authorization bug which allows users who have the ability to update at least one cluster secret to update any cluster secret. The attacker could use this access to escalate privileges (potentially controlling Kubernetes resources) or to break Argo CD functionality (by preventing connections to external clusters). How the Attack Works Argo CD stores cluster access configurations as Kubernetes Secrets. To take advantage of the vulnerability, an attacker must know the server URL for the cluster secret they want to modify. The attacker must be authenticated with the Argo CD API server, and they must be authorized to update at least one (non project-scoped) cluster. Then they must craft a malicious request to the Argo CD API server. Removing Deployment Restrictions A cluster Secret's clusterResources field determines whether Argo CD users may deploy cluster-scoped resources to that cluster. The namespaces…
Recommended action: Upgrade to 2.6.2, 2.5.11, 2.4.23 or 2.3.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 All versions of Argo CD starting with v1.8.2 are vulnerable to an improper authorization bug causing the API to accept certain invalid tokens. OIDC providers include an aud (audience) claim in signed tokens. The value of that claim specifies the intended audience(s) of the token (i.e. the service or services which are meant to accept the token). Argo CD does validate that the token was signed by Argo CD's configured OIDC provider. But Argo CD does not validate the audience claim, so it will accept tokens that are not intended for Argo CD. If Argo CD's configured OIDC provider also serves other audiences (for example, a file storage service), then Argo CD will accept a token intended for one of those other audiences. Argo CD will grant the user privileges based on the token's groups claim, even though those groups were not intended to be used by Argo CD. This bug also increases the blast radius of a stolen token. If an attacker steals a valid token for a different audience,…
Recommended action: Upgrade to 2.6.0-rc5 (pre-release), 2.5.8, 2.4.20 or 2.3.14 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 >= 2.3.0, < 2.3.6; >= 2.4.0, < 2.4.5
Fixed in
2.4.52.3.6· Vendor fix available
Issue
Impact All versions of Argo CD starting with 2.3.0 are vulnerable to a cross-site scripting (XSS) bug which could allow an attacker to inject arbitrary JavaScript in the /auth/callback page in a victim's browser. This vulnerability only affects Argo CD instances which have SSO enabled. The exploit also assumes the attacker has 1) access to the API server's encryption key, 2) a method to add a cookie to the victim's browser, and 3) the ability to convince the victim to visit a malicious /auth/callback link. The vulnerability is classified as low severity, because access to the API server's encryption key already grants a high level of access. Exploiting the XSS would allow the attacker to impersonate the victim, but would not grant any privileges which the attacker could not otherwise gain using the encryption key. Patches A patch for this vulnerability has been released in the following Argo CD versions: v2.4.5 v2.3.6 Workarounds There is no workaround besides upgrading. Credits…
Recommended action: Upgrade to 2.4.5 or 2.3.6 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.4.0 are vulnerable to an improper certificate validation bug which could cause Argo CD to trust a malicious (or otherwise untrustworthy) OIDC provider. (Note: external OIDC provider support was added in v0.11.0. Before that version, the notes below apply only to the bundled Dex instance.) You are impacted if 1) have SSO enabled and 2) insecure mode is not enabled on the API server. In this case, certificate verification is skipped when connecting to your OIDC provider for the following tasks: verifying auth tokens on API requests and handling SSO login flows. If you are using the bundled Dex instance but have not set the --dex-server flag on the API server to an HTTPS address, then certificate verification is not being skipped (because TLS is not enabled by default for the bundled Dex instance). Argo CD sends requests to the configured OIDC provider (either the bundled Dex instance or an external provider) to 1) retrieve the OpenID…
Recommended action: Upgrade to 2.4.5, 2.3.6 or 2.2.11 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.1.16 or later, 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.1.16 or later, 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.1.16 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 >= 0.11.0, <= 1.8.7
Fixed in
2.1.16· Vendor fix available
Issue
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.1.16 or later, 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.1.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Argo versions prior to v1.5.0-rc1, it was possible for authenticated Argo users to submit API calls to retrieve secrets and other manifests which were stored within git.
Recommended action: Upgrade to 1.5.0-rc1 (pre-release) or later, 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.1.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Impacts for versions starting with v1.0.0 All unpatched versions of Argo CD starting with v1.0.0 are vulnerable to an improper access control bug, allowing a malicious user to potentially escalate their privileges to admin-level. To perform the following 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: 1. If that user has update access to the Application, they can modify any resource on the Application's destination cluster. If the destination cluster is or can be made to be the same as the cluster hosting Argo CD, the user can escalate their Argo CD permissions to admin-level. 2. If the user has delete access to the Application, they can delete any resource on the Application's destination cluster. (This exploit is possible starting with v0.8.0.) 3. If the…
Recommended action: Upgrade to 2.3.2, 2.2.8 or 2.1.14 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.5.0 are vulnerable to a path traversal vulnerability allowing 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 other Application's source repositories (potentially decrypted files, if you are using a decryption plugin) or any 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.3.0 v2.2.6 v2.1.11 Workarounds The only certain…
Recommended action: Upgrade to 2.3.0, 2.2.6 or 2.1.11 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 path traversal bug, compounded by an improper access control bug, 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/{repourl}/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. Contents from a non-YAML file may be returned as part of 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 other Applications' source repositories (potentially decrypted files, if you are using a decryption plugin) or any secrets which have been mounted as…
Recommended action: Upgrade to 2.3.0, 2.2.6 or 2.1.11 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 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.1.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Fixed in v1.5.1, Argo version v1.5.0 was vulnerable to a user-enumeration vulnerability which allowed attackers to determine the usernames of valid (non-SSO) accounts because /api/v1/session returned 401 for an existing username and 404 otherwise. Specific Go Packages Affected github.com/argoproj/argo-cd/util/session github.com/argoproj/argo-cd/server/session
Recommended action: Upgrade to 1.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
As of v1.5.0, the Argo API does not implement anti-automation measures such as rate limiting, account lockouts, or other anti-bruteforce measures. Attackers can submit an unlimited number of authentication attempts without consequence. Specific Go Packages Affected github.com/argoproj/argo-cd/util/cache
Recommended action: Upgrade to 1.5.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 < 1.7.14; >= 1.8.0, < 1.8.7
Fixed in
1.7.141.8.7· Vendor fix available
Issue
Impact When Argo CD was connected to a Helm OCI repository with authentication enabled, the credentials used for accessing the remote repository were logged. Anyone with access to the pod logs - either via access with appropriate permissions to the Kubernetes control plane or a third party log management system where the logs from Argo CD were aggregated - could have potentially obtained the credentials to the Helm OCI repository. If you are using Helm OCI repositories with Argo CD, it is strongly recommended to upgrade Argo CD to the latest patch version and to change the credentials used to access the repositories. Patches A patch for this vulnerability is available with the v1.8.7 and v1.7.14 releases of Argo CD. Workarounds No workaround available References N/A 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 and…
Recommended action: Upgrade to 1.8.7 or 1.7.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.