Apache HttpComponents Client: TLS hostname verification silently disabled on the async transport (default config, MITM)
Improper TLS hostname verification vulnerability in Apache HttpComponents Client 5.4 or newer.
Red Hat build of Quarkus 3.27.5.SP1 release and security update
Released 2026-09-03 · Red Hat rating Important · View on Red Hat →
Improper TLS hostname verification vulnerability in Apache HttpComponents Client 5.4 or newer.
Netty (io.netty:netty-handler) versions from 4.2.0.Final through 4.2.16.Final and versions through 4.1.136.Final disable TLS hostname verification on the SslProvider.OPENSSL client path when a plain (non-extended) X509Tr…
A flaw was found in the Qute template engine, which is used by Quarkus to generate dynamic content like HTML pages or emails.
A flaw was found in SmallRye GraphQL.
A pre-authentication attacker could leverage type nesting to cause a StackOverflowError potentially leading to denial of service.
A pre-authentication attacker could leverage type size/count handling to cause excessive allocation leading to potential denial of service.
A pre-authentication attacker could leverage unbounded symbol value caching to cause resource exhaustion leading to denial of service.
A flaw was found in RESTEasy's SourceProvider.
A MongoDB driver component could write sensitive configuration information, including a credential used for outbound network connectivity, to application log output in cleartext during routine client initialization.
IBM Enterprise Build of Quarkus 3.27.1 through 3.27.5, and 3.33.1 through 3.33.3 could allow an attacker to bypass authorization by manipulating URL query parameters due to incorrect mapping of values to untrusted query…
Netty is an asynchronous, event-driven network application framework.
HttpClient based on the classic i/o model fails to correctly release the underlying connection back to the connection manager if it encounters an invalid or unsupported `Content-Encoding` header value in the response mes…
When a Quarkus application has multiple endpoints secured by individual OIDC provider tenants, such as "/oidc-provider1" that is secured by the OIDC Provider 1 and "/oidc-provider2" that is secured by the OIDC Provider 2…