Threats Tagged 'cve-2026-56819'

Red Hat Streams for Apache Kafka, based on the Apache Kafka project, offers a distributed backbone that allows microservices and other applications to share data with extremely high throughput and extremely low latency. This release of Red Hat Streams for Apache Kafka 3.2.1 serves as a replacement for Red Hat Streams for Apache Kafka 3.2.0, and includes security and bug fixes, and enhancements. Security Fix(es): * golang-github-danielqsj-kafka_exporter: Go crypto/tls: Denial of Service via multiple TLS 1.3 key update messages (CVE-2026-32283) * quarkus-vertx-http: io.quarkus:quarkus-vertx-http: Authorization bypass via semicolons in HTTP requests (CVE-2026-39852) * kafka-clients: Apache Kafka Clients: Information disclosure and data corruption due to race condition in producer buffer management (CVE-2026-35554) * log4j-layout-template-json: Apache Log4j JsonTemplateLayout: Denial of Service via invalid JSON output (CVE-2026-34481) * log4j-core: Apache Log4j Core: Invalid XML output causes denial of service in logging (CVE-2026-34480) * log4j-core: Apache Log4j Core: Log injection via CRLF sequences due to configuration attribute renames (CVE-2026-34478) * netty-codec-dns: Netty: High integrity impact due to improper DNS domain name constraint enforcement (CVE-2026-42579) * netty-codec-http: Netty: Incorrect HTTP response parsing leads to data confusion (CVE-2026-42584) * netty-codec-http: Netty: HTTP Request Smuggling due to improper handling of conflicting HTTP/1.0 headers (CVE-2026-42581) * netty-handler-proxy: Netty: HTTP Header Injection via HttpProxyHandler Disabled Validation (CVE-2026-42578) * netty-codec-http: Netty: Denial of Service via unbounded memory allocation in HTTP content decompression (CVE-2026-42587) * netty-codec-http2: Netty: Denial of Service via unbounded memory allocation in HTTP content decompression (CVE-2026-42587) * netty-codec: Netty: Denial of Service via excessive memory allocation in LZ4FrameDecoder (CVE-2026-42583) * netty-codec-compression: Netty: Denial of Service via excessive memory allocation in LZ4FrameDecoder (CVE-2026-42583) * next: Next.js: Authorization bypass via crafted query parameters (CVE-2026-44574) * next: Next.js: Denial of Service via crafted POST requests to server actions (CVE-2026-44579) * next: Next.js: Denial of Service via Image Optimization API (CVE-2026-44577) * next: Next.js: Information disclosure due to middleware bypass in Pages Router with i18n (CVE-2026-44573) * next: Next.js: Server-Side Request Forgery via crafted WebSocket upgrade requests (CVE-2026-44578) * next: Next.js: Information disclosure via security fix bypass in middleware with Turbopack (CVE-2026-45109) * next: Next.js: Unauthorized access to protected content via middleware bypass (CVE-2026-44575) * quarkus-vertx-http: Quarkus: Authorization bypass in HTTP path-based policies via encoded characters (CVE-2026-50559) * golang-github-danielqsj-kafka_exporter: golang.org/x/net/idna: Privilege escalation via incorrect Punycode label processing (CVE-2026-39821) * vertx-core: eclipse-vertx/vert.x: Denial of Service via TLS handshake with wildcard server name (CVE-2026-6860) * netty-handler: netty-handler: IPv6 subnet rule bypass due to incorrect masking operation (CVE-2026-44249) * netty-codec-haproxy: Netty-codec-haproxy: Denial of Service via malformed HAProxy message (CVE-2026-44893) * netty-codec-http2: netty-codec-http2: Denial of Service due to resource leak (CVE-2026-48043) * netty-codec-haproxy: Netty HAProxy PROXY protocol v2 codec: Denial of Service via memory leak from crafted PROXY protocol headers (CVE-2026-48059) * netty-resolver-dns: Netty has Insufficient Bailiwick Validation for NS Records (CVE-2026-47691) * netty-resolver-dns: Netty: Information disclosure and data manipulation due to improper CNAME record validation (CVE-2026-45674) * netty-handler: Netty: Denial of Service due to eager buffer allocation in TLS handshake (CVE-2026-45416) * golang-github-danielqsj-kafka_exporter: Go net package: Denial of Service via long CNAME response in LookupCNAME (CVE-2026-33811) * cluster-operator: Cross-namespace privilege escalation via Kafka.spec.entityOperator.watchedNamespace in Strimzi (CVE-2026-55225) * micrometer-core: Micrometer: Denial of Service via specially crafted HTTP requests (CVE-2026-40984) * micrometer-core: Micrometer: Denial of Service via specially crafted gRPC requests (CVE-2026-40983) * golang-github-danielqsj-kafka_exporter: golang crypto/x509: Denial of Service via excessive processing of DNS SAN entries (CVE-2026-27145) * jackson-databind: jackson-databind: Arbitrary code execution via PolymorphicTypeValidator bypass (CVE-2026-54512) * jackson-databind: Jackson-databind: Denial of Service via deeply nested JSON processing (CVE-2026-50193) * golang-github-danielqsj-kafka_exporter: Golang MIME: Denial of Service via maliciously-crafted MIME header (CVE-2026-42504) * jacks

### Summary A remote, unauthenticated peer can leak one direct `ByteBuf` per HTTP/2 `DATA` frame in applications that enable HTTP/2 content decompression via `DelegatingDecompressorFrameListener`. When a `DATA` frame is processed for a stream whose decompressor has already been closed, `Http2Decompressor.decompress(...)` retains the frame buffer but never releases it on the error path, so its reference count never returns to zero. Repeating this over a long-lived HTTP/2 connection exhausts direct memory and crashes the JVM with `OutOfMemoryError` — a denial of service. ### Details In `codec-http2/src/main/java/io/netty/handler/codec/http2/DelegatingDecompressorFrameListener.java`, `Http2Decompressor.decompress(...)` does: ```java // around line 433 decompressor.writeInbound(data.retain()); ``` The argument `data.retain()` is evaluated **before** `writeInbound(...)` executes, incrementing the buffer's reference count (`refCnt: 1 -> 2`). The very first statement of `EmbeddedChannel.writeInbound(...)` is `ensureOpen()` (`EmbeddedChannel.java:360`), which throws `ClosedChannelException` when the decompressor's internal `EmbeddedChannel` has already been closed. When that happens: - the `DATA` payload has been `retain()`ed but never entered the pipeline, so the decoder's `finally { release() }` never runs; - the surrounding `catch (Throwable t)` block in `decompress(...)` (around line 451) does **not** release the extra reference; - the input buffer therefore can never reach refCnt 0, and its (typically direct) memory is leaked. The decompressor channel is closed on a reachable path: `Http2Connection` `onStreamRemoved` → `Http2Decompressor.cleanup()` → `EmbeddedChannel.finishAndReleaseAll()` (`DelegatingDecompressorFrameListener.java:125-133` and `418-420`). A peer that sends `DATA` frames for a stream whose decompressor has already been cleaned up (e.g. continuing to send `DATA` after `END_STREAM` / stream removal) thus leaks one direct `ByteBuf` per frame. **Affected code**: `DelegatingDecompressorFrameListener.java`, method `Http2Decompressor.decompress(...)` — the `decompressor.writeInbound(data.retain())` call (line ~433) and its `catch (Throwable t)` block (line ~451), which lacks a `data.release()` rollback. **Suggested fix**: track whether `writeInbound` succeeded and roll back the extra `retain()` only when the data never entered the pipeline: ```java boolean writeSucceeded = false; try { decompressor.writeInbound(data.retain()); writeSucceeded = true; // pipeline now owns the release if (endOfStream) { decompressor.finish(); } return 0; } catch (Throwable t) { if (!writeSucceeded) { data.release(); // roll back the extra retain(); data never entered pipeline } if (t instanceof Http2Exception) { throw (Http2Exception) t; } throw streamError(stream.id(), INTERNAL_ERROR, t, ...); } ``` | Case | writeSucceeded | catch action | Reason | |------|:---:|---|---| | `ensureOpen()` throws (this bug) | `false` | `data.release()` | data never entered pipeline | | handler throws internally | `true` | no release | decoder `finally` already released | | `finish()` throws | `true` | no release | `writeInbound` already succeeded | ### PoC Reproduced against the official, unmodified `netty-codec-http2-4.2.15.Final.jar` from Maven Central, using real netty classes and measuring `ByteBuf.refCnt()` directly (the leaking logic is not mocked). Reproduction steps: 1. Download the official artifacts and their dependencies from Maven Central (version `4.2.15.Final`): `netty-common`, `netty-buffer`, `netty-transport`, `netty-resolver`, `netty-handler`, `netty-codec-base`, `netty-codec`, `netty-codec-http`, `netty-codec-http2`, `netty-codec-compression`. 2. Build a real `Http2Decompressor` wrapping a real gzip decoder `EmbeddedChannel` (`ZlibCodecFactory.newZlibDecoder(ZlibWrapper.GZIP)`). 3. Close the internal decompressor channel (equivalent to the end state of `cleanup()` / `finishAndReleaseAll()`). 4. Encode a real gzip `DATA` payload with `ZlibCodecFactory.newZlibEncoder(GZIP)` (`refCnt = 1`). 5. Call `decompress(...)` on the closed channel. 6. Observe: `writeInbound(...)` throws `ClosedChannelException` at its `ensureOpen()` entry (`EmbeddedChannel.java:360`), reached from `DelegatingDecompressorFrameListener.java:433`; `data.refCnt()` is now `2`. 7. Release once as the frame reader would; `refCnt` stays at `1` (`release()` returns `false`) → leaked. Observed reference-count trace: ``` gzipData initial refCnt = 1 decompress -> data.retain() -> refCnt = 2 (retain applied, never rolled back) caller releases once -> refCnt = 1 (release() returns false; not deallocated) => buffer never reaches 0 -> direct memory leaked ``` Observed exception stack (confirms the leak point): ``` java.nio.channels.ClosedChannelException at io.netty.channel.embedded.EmbeddedChannel.checkO

An update for Red Hat Build of Apache Camel 4.18.3 for Quarkus 3.33 update is now available (RHBQ 3.33.2.SP3). The purpose of this text-only errata is to inform you about the enhancements that improve your developer experience and ensure the security and stability of your products: * netty-codec-http: Netty: Memory exhaustion in netty-codec-http (decompression bomb) [rhboac-camel-quarkus-3] (CVE-2026-59899) * netty-codec-http2: Netty: Denial of Service via HTTP/2 DATA frame memory leak [rhboac-camel-quarkus-3] (CVE-2026-56819) * netty-codec-http: Netty: Security control bypass allows unauthorized requests via null origin header [rhboac-camel-quarkus-3] (CVE-2026-56746) * netty-codec-http: Netty: Denial of Service via memory exhaustion in SPDY-to-HTTP codec [rhboac-camel-quarkus-3] (CVE-2026-56745) * netty-codec-haproxy: Netty codec-haproxy: Denial of Service via crafted PROXY protocol v2 message [rhboac-camel-quarkus-3] (CVE-2026-55851) * netty-codec-http: Netty: Denial of Service via SPDY SETTINGS frame processing [rhboac-camel-quarkus-3] (CVE-2026-55831) * vertx-web-client: Eclipse Vert.x Web Client: Information disclosure via improper cookie domain validation [rhboac-camel-quarkus-3] (CVE-2026-15076) * smallrye-mutiny-vertx-core: Eclipse Vert.x: Information disclosure via improper handling of HTTP 30x redirects [rhboac-camel-quarkus-3] (CVE-2026-15075) * vertx-core: Eclipse Vert.x: Information disclosure via improper handling of HTTP 30x redirects [rhboac-camel-quarkus-3] (CVE-2026-15075) * httpcore5-h2: Apache HttpComponents Core: Denial of Service via oversized HTTP/2 HPACK header blocks [rhboac-camel-quarkus-3] (CVE-2026-54428) * camel-vertx-http: Apache Camel (camel-vertx-http): Remote Code Execution via Deserialization of Untrusted Data [rhboac-camel-quarkus-3] (CVE-2026-40859) * camel-mail: Apache Camel Mail Component: Credential exposure and information disclosure via improper input validation of mail headers [rhboac-camel-quarkus-3] (CVE-2026-46584) * camel-cxf-common: Apache Camel CXF SOAP: Remote attacker can execute unintended operations via header manipulation [rhboac-camel-quarkus-3] (CVE-2026-46592) * camel-vertx-websocket: Apache Camel Vertx Websocket: Server-Side Request Forgery and sensitive data exposure [rhboac-camel-quarkus-3] (CVE-2026-46726) * httpcore: Apache HttpComponents Core: Denial of Service via excessive HTTP headers [rhboac-camel-quarkus-3] (CVE-2026-54399)