ghsa

Mattermost versions 10.5.x <= 10.5.10, 10.11.x <= 10.11.2 fail to properly validate guest user permissions when accessing channel information which allows guest users to discover active public channels and their metadata via the `/api/v4/teams/{team_id}/channels/ids` endpoint

Mattermost versions 10.11.x <= 10.11.1, 10.10.x <= 10.10.2, 10.5.x <= 10.5.10 fail to verify a user has permission to join a Mattermost team using the original invite token which allows any attacked to join any team on a Mattermost server regardless of restrictions via manipulating the RelayState.

Mattermost versions 10.11.x <= 10.11.1, 10.10.x <= 10.10.2, 10.5.x <= 10.5.10 fail to verify a user has permission to join a Mattermost team using the original invite token which allows any attacked to join any team on a Mattermost server regardless of restrictions via manipulating the OAuth state.

Mattermost versions 10.5.x <= 10.5.10, 10.11.x <= 10.11.2 fail to properly validate guest user permissions when adding channel members which allows guest users to add any team members to their private channels via the `/api/v4/channels/{channel_id}/members` endpoint

### Impact The GeoIP processor in Data Prepper was configured to trust all SSL certificates and disable hostname verification when downloading GeoIP databases from HTTP URLs, making downloads vulnerable to man-in-the-middle attacks. The GeoIP processor included a custom SSL implementation that completely bypassed certificate validation when downloading GeoIP databases from external sources. The `initiateSSL()` method incorrectly implemented an approach for trusting all certificates. Specifically it: * Accepted all SSL certificates without validation * Disabled server certificate verification * Disabled client certificate verification * Disabled hostname verification This configuration made database downloads vulnerable to man-in-the-middle attacks, potentially allowing attackers to serve malicious GeoIP databases that could compromise the integrity of geolocation data processing. ### Patches Data Prepper 2.12.2 contains a fix for this issue. ### Workarounds If upgrading is not ...

### Impact The GeoIP processor and Kafka source and buffer were using the deprecated "SSL" protocol identifier when creating SSL contexts, potentially allowing the use of insecure SSL protocols instead of modern TLS versions. Multiple Data Prepper plugins used `SSLContext.getInstance("SSL")` which could potentially allow the use of deprecated SSL protocols (SSLv2, SSLv3) that have known security vulnerabilities. While modern Java implementations typically default to secure TLS versions even with the "SSL" identifier, explicitly using "TLS" ensures that only secure TLS protocols are negotiated. The affected components were: * GeoIP Processor: The `DBSource.initiateSSL()` method used for downloading GeoIP databases from external sources * Kafka Plugin: Both `CustomClientSslEngineFactory` and `InsecureSslEngineFactory` classes used for Kafka client connections This could potentially allow connections to negotiate weaker SSL protocols instead of enforcing modern TLS versions, reducin...

### Summary The mitigation proposed in GHSA-37j7-fg3j-429f for disabling eval/Function when executing untrusted code in happy-dom does not suffice, since it still allows prototype pollution payloads. ### Details The untrusted script and the rest of the application still run in the same Isolate/process, so attackers can deploy prototype pollution payloads to hijack important references like "process" in the example below, or to hijack control flow via flipping checks of undefined property. There might be other payloads that allow the manipulation of require, e.g., via (univeral) gadgets (https://www.usenix.org/system/files/usenixsecurity23-shcherbakov.pdf). ### PoC Attackers can pollute builtins like Object.prototype.hasOwnProperty() to obtain important references at runtime, e.g., "process". In this way, attackers might be able to execute arbitrary commands like in the example below via spawn(). ```js import { Browser } from "happy-dom"; const browser = new Browser({settings: {enab...

### Impact This vulnerability only affects users of the AWS attestor. Users of the AWS attestor could have unknowingly received a forged identity document. While this may seem unlikely, AWS recently issued a security bulletin about IMDS (Instance Metadata Service) impersonation.[^1] There are multiple locations where the verification of the identity document will mistakenly report a successful verification. - If a signature is not present or is empty https://github.com/in-toto/go-witness/blob/0c8bb30c143951d88b1d4b32f260c5f67d30137b/attestation/aws-iid/aws-iid.go#L161-L163 - If the RSA verification of the document fails for any reason https://github.com/in-toto/go-witness/blob/0c8bb30c143951d88b1d4b32f260c5f67d30137b/attestation/aws-iid/aws-iid.go#L192-L196 ### Workarounds The contents of the AWS attestation contain the identity document, signature, and public key that was used to verify the document. These attestations and their could be identity documents could be manually verif...

### Impact The OpenSearch sink and source plugins in Data Prepper are configured to trust all SSL certificates by default when no certificate path was provided, making connections vulnerable to man-in-the-middle attacks. Prior to this fix, the OpenSearch sink and source plugins would automatically use a trust all SSL strategy when connecting to OpenSearch clusters if no certificate path was explicitly configured. This behavior bypassed SSL certificate validation, potentially allowing attackers to intercept and modify data in transit through man-in-the-middle attacks. The vulnerability affects connections to OpenSearch when the `cert` parameter is not explicitly provided. ### Patches Data Prepper 2.12.2 ### Workarounds If you cannot immediately upgrade to the fixed version, you can implement the following workaround. #### OpenSearch sink Add the `cert` parameter to your OpenSearch sink configuration with the path to your cluster's CA certificate. The following example shows how...

### Summary `sveltekit-superforms` v2.27.3 and prior are susceptible to a prototype pollution vulnerability within the `parseFormData` function of `formData.js`. An attacker can inject string and array properties into `Object.prototype`, leading to denial of service, type confusion, and potential remote code execution in downstream applications that rely on polluted objects. ### Details Superforms is a SvelteKit form library for server and client form validation. Under normal operation, form validation is performed by calling the the `superValidate` function, with the submitted form data and a form schema as arguments: ```js // https://superforms.rocks/get-started#posting-data const form = await superValidate(request, your_adapter(schema)); ``` Within the `superValidate` function, a call is made to `parseRequest` in order to parse the user's input. `parseRequest` then calls into `parseFormData`, which in turn looks for the presence of `__superform_json` in the form parameters. If `_...