ghsa

### Impact Password reset form is vulnerable to CSRF between time reset password link is clicked and user submits new password. ### Patches Versions 19.4.22 and 20.0.19 contain patches. ### Workarounds None ### References See https://hackerone.com/reports/1086752

### 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...

### Impact A command injection vulnerability was discovered in Wrangler's Git package affecting versions up to and including `v1.0.0`. Wrangler's Git package uses the underlying Git binary present in the host OS or container image to execute Git operations. Specially crafted commands can be passed to Wrangler that will change their behavior and cause confusion when executed through Git, resulting in command injection in the underlying host. ### Workarounds A workaround is to sanitize input passed to the Git package to remove potential unsafe and ambiguous characters. Otherwise, the best course of action is to update to a patched Wrangler version. ### Patches Patched versions include `v1.0.1` and later and the backported tags - `v0.7.4-security1`, `v0.8.5-security1` and `v0.8.11`. ### For more information If you have any questions or comments about this advisory: * Reach out to [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related...

### Impact A denial of services (DoS) vulnerability was discovered in Wrangler Git package affecting versions up to and including `v1.0.0`. Specially crafted Git credentials can result in a denial of service (DoS) attack on an application that uses Wrangler due to the exhaustion of the available memory and CPU resources. This is caused by a lack of input validation of Git credentials before they are used, which may lead to a denial of service in some cases. This issue can be triggered when accessing both private and public Git repositories. ### Workarounds A workaround is to sanitize input passed to the Git package to remove potential unsafe and ambiguous characters. Otherwise, the best course of action is to update to a patched Wrangler version. ### Patches Patched versions include `v1.0.1` and later and the backported tags - `v0.7.4-security1`, `v0.8.5-security1` and `v0.8.11`. ### For more information If you have any questions or comments about this advisory: * Reach out t...

### 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.n...

### Impact This issue affects Rancher versions from 2.5.0 up to and including 2.5.16, from 2.6.0 up to and including 2.6.9 and 2.7.0. It only affects Rancher setups that have an external [authentication provider](https://ranchermanager.docs.rancher.com/pages-for-subheaders/authentication-config) configured or had one configured in the past. It was discovered that when an external authentication provider is configured in Rancher and then disabled, the Rancher generated [tokens](https://ranchermanager.docs.rancher.com/reference-guides/about-the-api/api-tokens) associated with users who had access granted through the now disabled auth provider are not revoked. This allows users to retain access to Rancher and `kubectl` access to clusters managed by Rancher, according to their previous configured permissions, even after they are supposed to have lost it due to the auth provider been disabled. The problem also occurs if the auth provider is configured (and is still enabled) to use the [a...

### Impact This issue affects Rancher versions from 2.5.0 up to and including 2.5.16, from 2.6.0 up to and including 2.6.9 and 2.7.0. It was discovered that the security advisory CVE-2021-36782 (GHSA-g7j7-h4q8-8w2f), previously released by Rancher, missed addressing some sensitive fields, secret tokens, encryption keys, and SSH keys that were still being stored in plaintext directly on Kubernetes objects like `Clusters`. The exposed credentials are visible in Rancher to authenticated `Cluster Owners`, `Cluster Members`, `Project Owners` and `Project Members` of that cluster on the endpoints: - `/v1/management.cattle.io.cluster` - `/v1/management.cattle.io.clustertemplaterevisions` The remaining sensitive fields are now stripped from `Clusters` and other objects and moved to a `Secret` before the object is stored. The `Secret` is retrieved when the credential is needed. For objects that existed before this security fix, a one-time migration happens on startup. The fields that have ...

### Impact An issue was discovered in Rancher from versions 2.5.0 up to and including 2.5.16, 2.6.0 up to and including 2.6.9 and 2.7.0, where a command injection vulnerability is present in the Rancher Git package. This package uses the underlying Git binary available in the Rancher container image to execute Git operations. Specially crafted commands, when not properly disambiguated, can cause confusion when executed through Git, resulting in command injection in the underlying Rancher host. This issue can potentially be exploited in Rancher in two ways: 1. Adding an untrusted Helm catalog, in the Catalogs menu, that contains maliciously designed repo URL configuration in Helm charts. 2. Modifying the URL configuration used to download KDM (Kontainer Driver Metadata) releases. By default, only the Rancher admin has permission to manage both configurations for the local cluster (the cluster where Rancher is provisioned). Note: More information about this category of issue in ver...

### Impact An issue was discovered in Rancher where an authorization logic flaw allows an authenticated user on any downstream cluster to (1) open a shell pod in the Rancher `local` cluster and (2) have limited `kubectl` access to it. The expected behavior is that a user does not have such access in the Rancher `local` cluster unless explicitly granted. This issue does not allow the user to escalate privileges in the `local` cluster directly (this would require another vulnerability to be exploited). The security issue happens in two different ways: 1. Shell pod access - This is when a user opens a shell pod in the Rancher UI to a downstream cluster that the user has permission to access. The web request can be intercepted using the browser's web inspector/network console or a proxy tool to change the shell's destination to the Rancher `local` cluster instead of the desired downstream cluster. - This flaw cannot be exploited to access a downstream cluster that the user has no p...

### Impact An issue was discovered in Rancher versions from 2.5.0 up to and including 2.5.16 and from 2.6.0 up to and including 2.6.9, where an authorization logic flaw allows privilege escalation via project role template binding (PRTB) and `-promoted` roles. This issue is not present in Rancher 2.7 releases. Note: Consult Rancher [documentation](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles) for more information about cluster and project roles and [KB 000020097](https://www.suse.com/support/kb/doc/?id=000020097) for information about `-promoted` roles. This privilege escalation is possible for users with access to the `escalate` verb on PRTBs (`projectroletemplatebindings.management.cattle.io`), including users with `*` verbs on PRTBs (see notes below for more information). These users can escalate permissions for any `-promoted` resource (see...