Most recent entries from all

Withdrawn: CLEANSTART-2026-KH48438 — Security fixes in keycloak 26.5.7-r1

Withdrawn by the publisher.

Affected: CleanStart: keycloak

Package keycloak version 26.5.7-r1 fixes 24 vulnerabilities: CVE-2026-44893, CVE-2026-44249, CVE-2026-45416, CVE-2026-45536, CVE-2026-45673...

EUVD-2026-317459

fkie_cve-2026-6860

A TCP client can perform a TLS handshake and present the server name extension with a server name that is accepted by a server wildcard name, e.g. if the server is configured with a certificate accepting *.example.com, any XYZ.example.com where xyz is a valid name can be used.

GHSA-3g76-f9xq-8vp6 — Vert.x has a DoS via unbounded server-side SNI SslContext cache growth

Affected: Maven: io.vertx:vertx-core

Potential unbounded server-side SNI `SslContext` cache growth in Vert.x TLS handling, with = resource-exhaustion / DoS impact. On affected versions, matching server-side SNI names are cached via `computeIfAbsent(serverName, ...)` in a serverName-keyed `SslContext` cache.

The implementation differs slightly by branch, but the same sink appears to be present in released versions `4.3.4` through `5.0.11`: - `4.3.x`: `SSLHelper` - `4.4.x` / `4.5.x`: `SslChannelProvider` - `5.0.x` and current `master`: `SslContextProvider`

When server-side SNI is enabled and wildcard or otherwise broad hostname mappings are used, an unauthenticated client can send many distinct matching SNI names and cause the server to retain increasing numbers of `SslContext` entries over time, leading to increasing memory consumption and possible DoS conditions.

## Steps to reproduce

1. Configure a Vert.x server with `setSsl(true)` and `setSni(true)`. 2. Use a keystore or mapping where many distinct SNI names match a wildcard or similarly broad rule. 3. Send repeated connections with distinct matching SNI values. 4. Observe that the SNI cache size grows with the number of unique matching names.

## What are the affected versions?

Affected released versions confirmed on `origin`: - `4.3.4` through `4.3.8` - `4.4.0` through `4.4.9` - `4.5.0` through `4.5.26` - `5.0.0` through `5.0.11`

Not affected by the same sink: - `4.0.x` through `4.2.x` - `4.3.0` through `4.3.3`

RHSA-2026:26017 — Red Hat Security Advisory: Red Hat build of Quarkus 3.33.2.SP1 security update

eclipse-vertx/vert.x: eclipse-vertx/vert.x: Denial of Service via TLS handshake with wildcard server name netty-handler: netty-handler: IPv6 subnet rule bypass due to incorrect masking operation netty-codec-haproxy: Netty-codec-haproxy: Denial of Service via malformed HAProxy message netty-handler: Netty: Denial of Service due to eager buffer allocation in TLS handshake netty-resolver-dns: Netty DNS resolver: DNS Cache Poisoning via predictable transaction IDs netty-resolver-dns: Netty: Information disclosure and data manipulation due to improper CNAME record validation netty-codec-http2: Netty: Denial of Service via uncontrolled HTTP/2 concurrent streams io.netty/netty-resolver-dns: Netty has Insufficient Bailiwick Validation for NS Records netty-codec-http2: netty-codec-http2: Denial of Service due to resource leak netty-codec-haproxy: Netty HAProxy PROXY protocol v2 codec: Denial of Service via memory leak from crafted PROXY protocol headers netty-handler: Netty: Improper trust manager handling leads to hostname verification bypass netty-codec-http: Netty: Data manipulation via request-boundary confusion in HttpObjectDecoder io.quarkus/quarkus-vertx-http: Quarkus: Authorization bypass in HTTP path-based policies via encoded characters netty-codec-http2: Netty: Denial of Service due to HTTP/2 max header size handling