ghsa

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

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, 10.5.x <= 10.5.0 fail to restrict bookmark creation and updates in archived channels, which allows authenticated users created or update bookmarked in archived channels

Mattermost versions 10.4.x <= 10.4.2, 10.3.x <= 10.3.3, 9.11.x <= 9.11.8, 10.5.x <= 10.5.0 fail to enforce MFA on plugin endpoints, which allows authenticated attackers to bypass MFA protections via API requests to plugin-specific routes.

Mattermost versions 10.4.x <= 10.4.2, 10.3.x <= 10.3.3, 9.11.x <= 9.11.8 fail to restrict command execution in archived channels, which allows authenticated users to run commands in archived channels.

### Impact The issue only occurs when the `CLIENT SETINFO` command times out during connection establishment. The following circumstances can cause such a timeout: 1. The client is configured to transmit its identity. This can be disabled via the `DisableIndentity` flag. 2. There are network connectivity issues 3. The client was configured with aggressive timeouts The impact differs by use case: * **Sticky connections**: Rather than using a connection from the pool on-demand, the caller can stick with a connection. Then you receive persistent out-of-order responses for the lifetime of the connection. * **Pipelines**: All commands in the pipeline receive incorrect responses. * **Default connection pool usage without pipelining**: When used with the default [ConnPool](https://github.com/redis/go-redis/blob/8fadbef84a3f4e7573f8b38e5023fd469470a8a4/internal/pool/pool.go#L77) once a connection is returned after use with [ConnPool#Put](https://github.com/redis/go-redis/blob/8fadbef84a3f4...

### Impact The `APIExport` Virtual Workspace can be used to manage objects in workspaces that bind that `APIExport` for resources defined in the `APIExport` or specified and accepted via permission claims. This allows an API provider (via their `APIExport`) scoped down access to workspaces of API consumers to provide their services properly. The identified vulnerability allows creating or deleting an object via the `APIExport` VirtualWorkspace in any arbitrary target workspace for pre-existing resources. By design, this should only be allowed when the workspace owner decides to give access to an API provider by creating an APIBinding. With this vulnerability, it is possible for an attacker to create and delete objects even if none of these requirements are satisfied, i.e. even if there is no APIBinding in that workspace at all or the workspace owner has created an APIBinding, but rejected a permission claim. ### Patches A fix for this issue has been identified and has been publish...

### Summary URLs starting with `//` are not parsed properly, and the request `REQUEST_FILENAME` variable contains a wrong value, leading to potential rules bypass. ### Details If a request is made on an URI starting with `//`, coraza will set a wrong value in `REQUEST_FILENAME`. For example, if the URI `//bar/uploads/foo.php?a=b` is passed to coraza: , `REQUEST_FILENAME` will be set to `/uploads/foo.php`. The root cause is the usage of `url.Parse` to parse the URI in [ProcessURI](https://github.com/corazawaf/coraza/blob/8b612f4e6e18c606e371110227bc7669dc714cab/internal/corazawaf/transaction.go#L768). `url.Parse` can parse both absolute URLs (starting with a scheme) or relative ones (just the path). `//bar/uploads/foo.php` is a valid absolute URI (the scheme is empty), `url.Parse` will consider `bar` as the host and the path will be set to `/uploads/foo.php`. ### PoC ```go package main import ( "fmt" "net/url" "os" "github.com/corazawaf/coraza/v3" ) const testRule = ` Sec...