ghsa

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

### Impact An issue was discovered in Rancher versions up to and including 2.6.9 and 2.7.0, where the `cattle-token` secret, used by the `cattle-cluster-agent`, is predictable. Even after the token is regenerated, it will have the same value. This issue is not present in Rancher 2.5 releases. The `cattle-token` is used by Rancher's `cattle-cluster-agent` to connect to the Kubernetes API of Rancher provisioned downstream clusters. The problem occurs because the `cattle-token` secret does not use any random value in its composition, which causes it to always be regenerated with the same value. This can pose a serious problem if the token is compromised and needs to be recreated for security purposes. The usage of the `cattle-token` by an unauthorized user allows to escalate privileges to the cluster owner of the affected downstream cluster. It does not allow access to Rancher's own local cluster (the cluster where Rancher is provisioned). ### Workarounds In case it is not possible t...

### Advisory title: Field-level security issue with .keyword fields ### Affected versions: OpenSearch 1.0.0-1.3.7 and 2.0.0-2.4.1 ### Patched versions: OpenSearch 1.3.8 and 2.5.0 ### Impact: There is an issue in the implementation of field-level security (FLS) and field masking where rules written to explicitly exclude fields are not correctly applied for certain queries that rely on their auto-generated .keyword fields. This issue is only present for authenticated users with read access to the indexes containing the restricted fields. ### Workaround: FLS rules that use explicit exclusions can be written to grant explicit access instead. Policies authored in this way are not subject to this issue. ### Patches: OpenSearch versions 1.3.8 and 2.5.0 contain a fix for this issue. ### For more information: If you have any questions or comments about this advisory, please contact AWS/Amazon Security via our issue reporting page (https://aws.amazon.com/security/vulnerability-reporting/)...

### Advisory title: Issue with whitespace in JWT roles ### Affected versions: OpenSearch 1.0.0-1.3.7 and 2.0.0-2.4.1 ### Patched versions: OpenSearch 1.3.8 and 2.5.0 ### Impact: OpenSearch uses JWTs to store role claims obtained from the Identity Provider (IdP) when the authentication backend is SAML or OpenID Connect. There is an issue in how those claims are processed from the JWTs where the leading and trailing whitespace is trimmed, allowing users to potentially claim roles they are not assigned to if any role matches the whitespace-stripped version of the roles they are a member of. This issue is only present for authenticated users, and it requires either the existence of roles that match, not considering leading/trailing whitespace, or the ability for users to create said matching roles. In addition, the Identity Provider must allow leading and trailing spaces in role names. ### Patches: OpenSearch versions 1.3.8 and 2.5.0 contain a fix for this issue. ### For more informa...

## Impact Several quadratic complexity bugs in commonmarker's underlying [`cmark-gfm`](https://github.com/github/cmark-gfm) library may lead to unbounded resource exhaustion and subsequent denial of service. The following vulnerabilities were addressed: * [CVE-2023-22483](https://github.com/github/cmark-gfm/security/advisories/GHSA-29g3-96g3-jg6c) * [CVE-2023-22484](https://github.com/github/cmark-gfm/security/advisories/GHSA-24f7-9frr-5h2r) * [CVE-2023-22485](https://github.com/github/cmark-gfm/security/advisories/GHSA-c944-cv5f-hpvr) * [CVE-2023-22486](https://github.com/github/cmark-gfm/security/advisories/GHSA-r572-jvj2-3m8p) For more information, consult the release notes for version [`0.23.0.gfm.7`](https://github.com/github/cmark-gfm/releases/tag/0.29.0.gfm.7). ## Mitigation Users are advised to upgrade to commonmarker version [`0.23.7`](https://rubygems.org/gems/commonmarker/versions/0.23.7).

### Description: A regular expression denial of service (ReDoS) vulnerability has been discovered in `ua-parser-js`. ### Impact: This vulnerability bypass the library's `MAX_LENGTH` input limit prevention. By crafting a very-very-long user-agent string with specific pattern, an attacker can turn the script to get stuck processing for a very long time which results in a denial of service (DoS) condition. ### Affected Versions: All versions of the library prior to version `0.7.33` / `1.0.33`. ### Patches: A patch has been released to remove the vulnerable regular expression, update to version `0.7.33` / `1.0.33` or later. ### References: [Regular expression Denial of Service - ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) ### Credits: Thanks to @Snyk who first reported the issue.

### Impact MITM can enable Zip-Slip. ### Vulnerability #### Vulnerability 1: `Scanner.java` There is no validation that the zip file being unpacked has entries that are not maliciously writing outside of the intended destination directory. https://github.com/hapifhir/org.hl7.fhir.core/blob/8c43e21094af971303131efd081503e5a112db4b/org.hl7.fhir.validation/src/main/java/org/hl7/fhir/validation/Scanner.java#L335-L357 This zip archive is downloaded over HTTP instead of HTTPS, leaving it vulnerable to compromise in-flight. https://github.com/hapifhir/org.hl7.fhir.core/blob/8c43e21094af971303131efd081503e5a112db4b/org.hl7.fhir.validation/src/main/java/org/hl7/fhir/validation/Scanner.java#L136 ##### Vulnerability 2: `TerminologyCacheManager.java` **Note:** While these links point to only one implementation, both implementations of `TerminologyCacheManager.java` are vulnerable to this as their code seems to be duplicated. - https://github.com/hapifhir/org.hl7.fhir.core/blob/f58b7acfb5e3...

### Summary If a malicious URI is passed to the library, the library can be tricked into performing an operation on a different API endpoint than intended. ### Details The [code Spotipy uses to parse URIs and URLs ](https://github.com/spotipy-dev/spotipy/blob/master/spotipy/client.py#L1942) accepts user data too liberally which allows a malicious user to insert arbitrary characters into the path that is used for API requests. Because it is possible to include `..`, an attacker can redirect for example a track lookup via `spotifyApi.track()` to an arbitrary API endpoint like playlists, but this is possible for other endpoints as well. Before the security advisory feature was enabled on GitHub, I was already in contact with Stéphane Bruckert via e-mail, and he asked me to look into a potential fix. My recommendation is to perform stricter parsing of URLs and URIs, which I implemented in the patch included at the end of the report. If you prefer, I can also invite you to a private for...