ghsa

Denial of Service due to improper input validation vulnerability for HTTP/2 requests in Apache Tomcat. When processing an HTTP/2 request, if the request exceeded any of the configured limits for headers, the associated HTTP/2 stream was not reset until after all of the headers had been processed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98. Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue.

Denial of Service via incomplete cleanup vulnerability in Apache Tomcat. It was possible for WebSocket clients to keep WebSocket connections open leading to increased resource consumption.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98. Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue.

### Impact The MsQuic server will continue to leak memory until no more is available, resulting in a denial of service. ### Patches The following patch was made: - Fix Memory Leak from Multiple Decodes of TP - https://github.com/microsoft/msquic/commit/5d070d661c45979946615289e92bb6b822efe9e9 ### Workarounds Beyond upgrading to the patched versions, there is no other workaround. ### MSRC CVE Info https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-26190

### Impact Cloudflare Quiche (through version 0.19.1/0.20.0) was affected by an unlimited resource allocation vulnerability causing rapid increase of memory usage of the system running quiche server or client. A remote attacker could take advantage of this vulnerability by repeatedly sending an unlimited number of 1-RTT CRYPTO frames after previously completing the QUIC handshake. Exploitation was possible for the duration of the connection which could be extended by the attacker. ### Patches Quiche 0.19.2 and 0.20.1 are the earliest versions containing the fix for this issue.

### Impact Cloudflare quiche was discovered to be vulnerable to unbounded storage of information related to connection ID retirement, which could lead to excessive resource consumption. Each QUIC connection possesses a set of connection Identifiers (IDs); see [RFC 9000 Section 5.1](https://datatracker.ietf.org/doc/html/rfc9000#section-5.1). Endpoints declare the number of active connection IDs they are willing to support using the active_connection_id_limit transport parameter. The peer can create new IDs using a NEW_CONNECTION_ID frame but must stay within the active ID limit. This is done by retirement of old IDs, the endpoint sends NEW_CONNECTION_ID includes a value in the retire_prior_to field, which elicits a RETIRE_CONNECTION_ID frame as confirmation. An unauthenticated remote attacker can exploit the vulnerability by sending NEW_CONNECTION_ID frames and manipulating the connection (e.g. by restricting the peer's congestion window size) so that RETIRE_CONNECTION_ID frames can on...

### Summary aiosmtpd is vulnerable to inbound SMTP smuggling. SMTP smuggling is a novel vulnerability based on not so novel interpretation differences of the SMTP protocol. By exploiting SMTP smuggling, an attacker may send smuggle/spoof e-mails with fake sender addresses, allowing advanced phishing attacks. This issue also existed in other SMTP software like Postfix (https://www.postfix.org/smtp-smuggling.html). ### Details Detailed information on SMTP smuggling can be found in the full blog post (https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/) or on the Postfix homepage (https://www.postfix.org/smtp-smuggling.html). (and soon on the official website https://smtpsmuggling.com/) ### Impact With the right SMTP server constellation, an attacker can send spoofed e-mails to inbound/receiving aiosmtpd instances.

A user endpoint didn't perform filtering on an incoming parameter, which was added directly to the application log. This could lead to an attacker injecting false log entries or corrupt the log file format. ### Patches This has been fixed in the CKAN 2.9.11 and 2.10.4 versions ### Workarounds Override the `/user/reset` endpoint to filter the `id` parameter in order to exclude newlines

A vulnerability was found in Quarkus. In certain conditions related to the CI process, git credentials could be inadvertently published, which could put the git repository at risk.

Improper Authentication vulnerability in Apache Pulsar Proxy allows an attacker to connect to the /proxy-stats endpoint without authentication. The vulnerable endpoint exposes detailed statistics about live connections, along with the capability to modify the logging level of proxied connections without requiring proper authentication credentials. This issue affects Apache Pulsar versions from 2.6.0 to 2.10.5, from 2.11.0 to 2.11.2, from 3.0.0 to 3.0.1, and 3.1.0. The known risks include exposing sensitive information such as connected client IP and unauthorized logging level manipulation which could lead to a denial-of-service condition by significantly increasing the proxy's logging overhead. When deployed via the Apache Pulsar Helm chart within Kubernetes environments, the actual client IP might not be revealed through the load balancer's default behavior, which typically obscures the original source IP addresses when externalTrafficPolicy is being configured to "Cluster" by defau...

The vulnerability allows authenticated users with only produce or consume permissions to modify topic-level policies, such as retention, TTL, and offloading settings. These management operations should be restricted to users with the tenant admin role or super user role. This issue affects Apache Pulsar versions from 2.7.1 to 2.10.5, from 2.11.0 to 2.11.3, from 3.0.0 to 3.0.2, from 3.1.0 to 3.1.2, and 3.2.0. 2.10 Apache Pulsar users should upgrade to at least 2.10.6. 2.11 Apache Pulsar users should upgrade to at least 2.11.4. 3.0 Apache Pulsar users should upgrade to at least 3.0.3. 3.1 Apache Pulsar users should upgrade to at least 3.1.3. 3.2 Apache Pulsar users should upgrade to at least 3.2.1. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.