ghsa

## Summary The AWS Cloud Development Kit (AWS CDK) [1] is an open-source software development framework for defining cloud infrastructure in code and provisioning it through AWS CloudFormation. The AWS CDK CLI [2] is a command line tool for interacting with CDK applications. Customers can use the CDK CLI to create, manage, and deploy their AWS CDK projects. An issue exists in the AWS CDK CLI where, under certain conditions, AWS credentials may be returned in the console output. Plugins that return an `expiration `property in the credentials object are affected by this issue. Plugins that omit the `expiration` property are not affected. ## Impact When customers run AWS CDK CLI commands with credential plugins and configure those plugins to return temporary credentials by including an `expiration` property, the AWS credentials retrieved by the plugin may be returned in the console output. Any user with access where the CDK CLI was ran would have access to this output. The followi...

### Impact The 3rd party authentication handling of Parse Server allows the authentication credentials of some specific authentication providers to be used across multiple Parse Server apps. For example, if a user signed up using the same authentication provider in two unrelated Parse Server apps, the credentials stored by one app can be used to authenticate the same user in the other app. Note that this only affects Parse Server apps that specifically use an affected 3rd party authentication provider for user authentication, for example by setting the Parse Server option `auth` to configure a Parse Server authentication adapter. See the [3rd party authentication docs](https://docs.parseplatform.org/parse-server/guide/#oauth-and-3rd-party-authentication) for more information on which authentication providers are affected. ### Patches The fix of this vulnerability requires to upgrade Parse Server to a version that includes the bug fix, as well as upgrade the client app to send a secu...

A remote code execution vulnerability exists in invoke-ai/invokeai versions 5.3.1 through 5.4.2 via the /api/v2/models/install API. The vulnerability arises from unsafe deserialization of model files using torch.load without proper validation. Attackers can exploit this by embedding malicious code in model files, which is executed upon loading. This issue is fixed in version 5.4.3.

A vulnerability has been identified in Redlib where an attacker can cause a denial-of-service (DOS) condition by submitting a specially crafted base2048-encoded DEFLATE decompression bomb to the restore_preferences form. This leads to excessive memory consumption and potential system instability, which can be exploited to disrupt Redlib instances. This vulnerability was introduced in 2e95e1fc6e2064ccfae87964b4860bda55eddb9a and fixed in 15147cea8e42f6569a11603d661d71122f6a02dc. ### Impact _What kind of vulnerability is it? Who is impacted?_ This vulnerability allows a remote attacker with network access to exploit the preference restoration mechanism by providing a compressed payload that expands dramatically upon decompression. The issue arises because the system automatically decompresses user-supplied data without enforcing size limits, potentially leading to: - Out-of-memory (OOM) conditions - OS-level resource exhaustion, potentially leading to broader system instability or cra...

### Summary Envoy's ext_proc HTTP filter is at risk of crashing if a local reply is sent to the external server due to the filter's life time issue. A known situation is the fail of a websocket handshake will trigger a local reply leading to the crash of Envoy. ### PoC If both websocket and ext_proc are enabled, a failed handshake will trigger a local reply, thus ext_proc will crash. ### Mitigation 1. Disable websocket traffic 2. Change the websocket response from backend to always return `101 Switch protocol` based on RFC. 3. Apply the patch and the ext_proc filter will not send the local reply that is generated by Envoy to the ext_proc server for processing. 4. Apply the patch that the router will cancel the upstream requests when sending a local reply. ### Impact Denial of service ### Reporter Vasilios Syrakis Fernando Cainelli

# Impact It is possible to bypass authorization checks within a Next.js application, if the authorization check occurs in middleware. # Patches * For Next.js 15.x, this issue is fixed in `15.2.3` * For Next.js 14.x, this issue is fixed in `14.2.25` * For Next.js versions `11.1.4` thru `13.5.6`, consult the below workaround. # Workaround If patching to a safe version is infeasible, it is recommend that you prevent external user requests which contain the `x-middleware-subrequest` header from reaching your Next.js application. ## Credits - Allam Rachid (zhero;) - Allam Yasser (inzo_)

### Impact In libcontainer, while creating a tenant container, the tenant builder accepts a list of capabilities to be added in the spec of tenant container. Code can be seen [here](https://github.com/youki-dev/youki/blob/9e63fa4da1672a78ca45100f3059a732784a5174/crates/libcontainer/src/container/tenant_builder.rs#L408) . The logic here adds the given capabilities to all capabilities of main container if present in spec, otherwise simply set provided capabilities as capabilities of the tenant container. However, GHSA-f3fp-gc8g-vw66 was opened on runc mentioning that setting inherited caps in any case for tenant container can lead to elevation of capabilities. For this, they added a fix [here](https://github.com/opencontainers/runc/blob/986451c24e17c8d4be3c454f60b1f7be4af3e8b4/exec.go#L234-L242) where they never set new inherited caps on tenant, and set ambient caps only if original container had inherited caps. Similarly crun never sets inherited caps as can be seen [here](https://git...

Mattermost versions 9.11.x <= 9.11.8 fail to prompt for explicit approval before adding a team admin to a private channel, which team admins to joining private channels via crafted permalink links without explicit consent from them.

Mattermost versions 10.4.x <= 10.4.2, 10.3.x <= 10.3.3, 9.11.x <= 9.11.8 fail to to enforce channel conversion restrictions, which allows members with permission to convert public channels to private ones to also convert private ones to public.

Mattermost versions 10.4.x <= 10.4.2, 10.3.x <= 10.3.3, 9.11.x <= 9.11.8 fail to enforce MFA on certain search APIs, which allows authenticated attackers to bypass MFA protections via user search, channel search, or team search queries.