ghsa

### Impact A remote client may send a request that is exactly `recv_bytes` (defaults to 8192) long, followed by a secondary request using HTTP pipelining. When request lookahead is disabled (default) we won't read any more requests, and when the first request fails due to a parsing error, we simply close the connection. However when request lookahead is enabled, it is possible to process and receive the first request, start sending the error message back to the client while we read the next request and queue it. This will allow the secondary request to be serviced by the worker thread while the connection should be closed. ### Patches Waitress 3.0.1 fixes the race condition. ### Workarounds Disable `channel_request_lookahead`, this is set to `0` by default disabling this feature. For this vulnerability this value is required to be changed from the default. ### For more information If you have any questions or comments about this advisory: * Open an issue in https://github.com...

### Summary A kyverno ClusterPolicy, ie. "disallow-privileged-containers," can be overridden by the creation of a PolicyException in a random namespace. ### Details By design, PolicyExceptions are consumed from any namespace. Administrators may not recognize that this allows users with privileges to non-kyverno namespaces to create exceptions. ### PoC 1. Administrator creates "disallow-privileged-containers" ClusterPolicy that applies to resources in the namespace "ubuntu-restricted" 2. Cluster user creates a PolicyException object for "disallow-privileged-containers" in namespace "ubuntu-restricted" 3. Cluster user creates a pod with a privileged container in "ubuntu-restricted" 4. Cluster user escalates to root on the node from the privileged container ### Impact Administrators attempting to enforce cluster security through kyverno policies, but that allow less privileged users to create resources

### Impact When a remote client closes the connection before waitress has had the opportunity to call `getpeername()` waitress won't correctly clean up the connection leading to the main thread attempting to write to a socket that no longer exists, but not removing it from the list of sockets to attempt to process. This leads to a busy-loop calling the write function. A remote attacker could run waitress out of available sockets with very little resources required. ### Patches Waitress 3.0.1 contains fixes that remove the race condition. ### Workarounds No work-around. ### References - https://github.com/Pylons/waitress/issues/418 - https://github.com/Pylons/waitress/pull/435

Mattermost versions 9.10.x <= 9.10.2, 9.11.x <= 9.11.1, 9.5.x <= 9.5.9 fail to check that the origin of the message in an integration action matches with the original post metadata which allows an authenticated user to delete an arbitrary post.

Mattermost versions 9.5.x <= 9.5.9 fail to properly filter the channel data when ElasticSearch is enabled which allows a user to get private channel names by using cmd+K/ctrl+K.

Mattermost versions 9.10.x <= 9.10.2, 9.11.x <= 9.11.1, 9.5.x <= 9.5.9 fail to sanitize user inputs in the frontend that are used for redirection which allows for a one-click client-side path traversal that is leading to CSRF in Playbooks

Mattermost versions 9.10.x <= 9.10.2, 9.11.x <= 9.11.1 and 9.5.x <= 9.5.9 fail to prevent detailed error messages from being displayed in Playbooks which allows an attacker to generate a large response and cause an amplified GraphQL response which in turn could cause the application to crash by sending a specially crafted request to Playbooks.

Apache NiFi 1.10.0 through 1.27.0 and 2.0.0-M1 through 2.0.0-M3 support a description field for Parameters in a Parameter Context configuration that is vulnerable to cross-site scripting. An authenticated user, authorized to configure a Parameter Context, can enter arbitrary JavaScript code, which the client browser will execute within the session context of the authenticated user. Upgrading to Apache NiFi 1.28.0 or 2.0.0-M4 is the recommended mitigation.

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-r9pp-r4xf-597r. This link is maintained to preserve external references. ## Original Description An issue in pyload-ng v0.5.0b3.dev85 running under python3.11 or below allows attackers to execute arbitrary code via a crafted HTTP request.

### Impact IdentityServer's local API authentication handler performs insufficient validation of the `cnf` claim in DPoP access tokens. This allows an attacker to use leaked DPoP access tokens at local api endpoints even without possessing the private key for signing proof tokens. Note that this only impacts custom endpoints within an IdentityServer implementation that have explicitly used the `LocalApiAuthenticationHandler` for authentication. It does not impact: - OAuth or OIDC protocol endpoints defined by IdentityServer, such as the authorize and token endpoints. - Typical UI pages within an IdentityServer implementation, which are not normally authorized with the local API authentication handler. - The use of DPoP to create sender-constrained tokens in IdentityServer that are consumed by external API resources. - The use of DPoP to sender-constrain refresh tokens issued to public clients. ## Are you affected? This vulnerability only affects IdentityServer implementations that a...