Apache Kafka EUVD-2026-112168

Requires an attacker to hold valid authentication to the Kafka cluster as any client - the vendor description explicitly states 'an authenticated client' and notes PushTelemetry is not gated by an ACL, so no special role or privilege beyond authentication is needed. It works against default configurations: telemetry.max.bytes defaults to 1 MB and bounds only the compressed size, and on affected versions there is no configuration that fully prevents the amplification (lowering telemetry.max.bytes only proportionally reduces, not eliminates, the worst-case decompressed size). No user interaction and no non-default feature flag are required. The primary limiting factor is the authentication requirement; note the input provides no CVSS vector, so the privilege level is taken from the vendor text rather than a confirmed PR metric.

This is a denial-of-service vulnerability (CWE-409, improper handling of highly compressed data) in Apache Kafka's broker-side PushTelemetry API, with no CVSS score or vector supplied in the input - severity must therefore be assessed independently rather than read off a vendor rating. The core signals are mixed-to-moderate: there is no CISA KEV listing, no public exploit or PoC reference, and no EPSS probability in the input, so there is no evidence of active or imminent exploitation. The vuln.today decision label is 'this_month', indicating a near-term but non-emergency priority rather than act_now/emergency. Impact is confined to availability: successful exploitation causes broker heap exhaustion and OutOfMemoryError (crash/degradation), with no confidentiality or integrity impact described. The amplification is genuinely dangerous in substance - a small, highly compressible payload (e.g. gzipped zeros) expands to hundreds of megabytes of heap, and the API is reachable by ANY authenticated client with no ACL gating, so the bar is low once a client can authenticate and cluster-wide availability can be hit by targeting multiple brokers. The main factor limiting real-world risk is that it is not remote-unauthenticated: the vendor description explicitly states an authenticated client is required. Net assessment: a legitimate, reasonably prioritized availability bug for any multi-tenant or externally-reachable Kafka deployment, but not a drop-everything emergency on the current signals (no KEV, no PoC, non-emergency decision label).

An authenticated Kafka client sends a PushTelemetry request (KIP-714) carrying a small, highly compressible metrics payload such as gzip-compressed zeros, whose compressed size stays under telemetry.max.bytes (default 1 MB). The broker validates only the compressed size, then ClientTelemetryUtils.decompress() expands it unbounded into hundreds of megabytes of heap; repeated or concurrent requests, optionally fanned out across multiple brokers, drive the JVM to OutOfMemoryError and crash or degrade the cluster. No public exploit or PoC reference is identified at time of analysis.