A flaw was found in ArgoCD. An improper authorization bug may allow an attacker to update at least one cluster secret, enabling them to change any other cluster secret. The attacker must know the URL for the targeted cluster and additionally it should be authenticated within the ArgoCD API server with enough privileges to update at least one cluster. A successful attack may lead to privilege escalations or denial of service.

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Versions of Argo CD starting with v1.8.2 and prior to 2.3.13, 2.4.19, 2.5.6, and 2.6.0-rc-3 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 impact of a stolen token. If an attacker steals a valid token for a different audience, they can use it to access Argo CD. A patch for this vulnerability has been released in versions 2.6.0-rc3, 2.5.6, 2.4.19, and 2.3.13. There are no workarounds.

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 argocd-cmd-params-cm ConfigMap or otherwise setting the --application-namespaces flags on the Application controller and API server components. The apps-in-any-namespace feature is in beta as of this Security Advisory's publish date.

The bug is also limited to Argo CD instances where sharding is enabled by increasing the replicas count for the Application controller.

Finally, the AppProjects' sourceNamespaces field acts as a secondary check against this exploit. To cause reconciliation of an Application in an out-of-bounds namespace, an AppProject must be available which permits Applications in the out-of-bounds namespace.

Patches

A patch for this vulnerability has been released in the following Argo CD versions:

v2.5.8 v2.6.0-rc5

Workarounds

Running only one replica of the Application controller will prevent exploitation of this bug.

Making sure all AppProjects' sourceNamespaces are restricted within the confines of the configured Application namespaces will also prevent exploitation of this bug.

Credits

Thanks to ChangZhuo Chen (@czchen) for finding the issue and for contributing the fix!

References

Documentation for apps-in-any-namespace

For more information

Open an issue in the Argo CD issue tracker or discussions Join us on Slack in channel #argo-cd