Kafka

I feel like that is not necessary, I tend to look at the current documentation for open source tools usually unless I am explicitly working with something that requires an older version, so I guess the ssl guide is enough for 4.4.0 On Tue, 27 Oct 2026 at 12:10, Gergely Harmadás <harmadasg@gmail.com> wrote: > Hi Chia-Ping, > > The plan sounds good to me. Since the document is really outdated, should > we also backport it to older supported releases like 4.3 and 4.2, what do > you think? > > > Thanks, > Gergely > > On Tue, 27 Oct 2026 at 03:48, Chia-Ping Tsai <chia7712@apache.org> wrote: > > > I haven’t looked at the PR yet: > https://github.com/apache/kafka/pull/23907 > > > > Doc fixes don’t need to wait for a release. Once the PR gets merged, we > > can file a patch to kafka-site to update the web site right away :) > > > > On 2026/10/21 22:01:28 Gergely Harmadás wrote: ...

Severity: important Affected versions: - Apache Kafka 0.11.0.0 through 4.1.2 - Apache Kafka 4.2.0 through 4.2.1 - Apache Kafka 4.3.0 through 4.3.1 Description: When a broker decodes a compressed record batch, the per-record decoder reads a declared body size from the decompressed stream and allocates a buffer of that size before validating it against the bytes available or any configured limit. The size is attacker-controlled, and the batch CRC does not constrain it, so a small (around 90-byte), CRC-valid compressed produce request can declare a body size of up to about 2 GiB and force the broker to attempt that allocation, raising OutOfMemoryError. The record size limit (max.message.bytes), the request size limit, and client/broker quotas bound only the compressed wire size, not the declared decompressed size. Impact: An authenticated principal with Write on a topic can crash broker request-handler threads (reached when a batch's codec differs from ...

Severity: important Affected versions: - Apache Kafka 0.10.0.0 through 4.1.2 - Apache Kafka 4.2.0 through 4.2.1 - Apache Kafka 4.3.0 through 4.3.1 Description: Several Kafka deserialization paths read a size or count field from input data and use it directly to allocate an array, collection, or byte buffer, with no check against the bytes actually available. A small crafted input can therefore declare a very large size and force a multi-gigabyte allocation. The affected paths are, in Kafka Streams, ProcessorRecordContext (header count), ChangedDeserializer (varint value length), CombinedKeySchema (foreign-key length, which could also produce a negative size), ProcessorMetadata (key length), and AssignmentInfo group-assignment decoding; and, in the clients library, ListDeserializer (used by ListSerde). Impact: An attacker can trigger the oversized allocation and raise an OutOfMemoryError that crashes the affected consumer or Kafka Streams thread; the b...

Severity: low Affected versions: - Apache Kafka 1.1.0 through 4.1.2 - Apache Kafka 4.2.0 through 4.2.1 - Apache Kafka 4.3.0 through 4.3.1 Description: Kafka Streams derives its stream-time clock from record timestamps. PunctuationSchedule.next() computed the next punctuation time as timestamp + (intervalsMissed + 1) * interval with no overflow check. A record with a timestamp at or near Long.MAX_VALUE advances stream time to that value, so the next stream-time punctuation overflows to a negative time. PunctuationQueue then re-queues that time and loops on it indefinitely while holding a lock, stalling the StreamThread. Impact: A single record is enough. The affected StreamThread stops processing, and because the record stays in the topic the hang returns on restart; an application whose partitions are all affected becomes unresponsive. Only the Streams application is affected, not the brokers or the cluster. Triggering it needs write access to a source t...

Severity: important Affected versions: - Apache Kafka 2.4.0 through 4.1.2 - Apache Kafka 4.2.0 through 4.2.1 - Apache Kafka 4.3.0 through 4.3.1 Description: Apache Kafka's code-generated readers for flexible protocol versions read a tagged-field count declared by the sender and retain a RawTaggedField object for each unknown field. That count was bounded only by the outer request frame size (socket.request.max.bytes); it was not checked against the remaining buffer bytes or capped. Because each entry can be encoded in as little as two bytes (unknown tag 0, size 0), a modest request can declare tens of millions of tagged fields and force one object allocation per declared field. Flexible request headers (header version 2, used by flexible APIs such as ApiVersions v3) are parsed this way, so the amplification applies to the request header itself. Impact: The flexible request header is parsed on the network thread before authorization, request dispatch, ...

Severity: important Affected versions: - Apache Kafka 3.3.0 through 4.1.2 - Apache Kafka 4.2.0 through 4.2.1 - Apache Kafka 4.3.0 through 4.3.1 Description: Apache Kafka's code-generated protocol readers pre-size an array's collection from the element count declared by the sender. That count is checked only against the bytes remaining in the request buffer, which assumes about one byte per element; because most elements need several bytes, a request can declare far more elements than the buffer holds and still pass. For a keyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count +1), so a request of a few tens of megabytes can force a heap allocation several times larger before any element is read. The pattern is emitted into every generated reader, so it affects all Kafka API types with an array field. Impact: Request parsing happens before any authorization check. On a listener that does not require authentic...

Severity: important Affected versions: - Apache Kafka 4.1.0 through 4.1.2 - Apache Kafka 4.2.0 through 4.2.1 - Apache Kafka 4.3.0 Description: A Kafka broker using SASL/OAUTHBEARER with the default validator (sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator) selects its implementation from configuration. When sasl.oauthbearer.jwks.endpoint.url is set, the validator verifies the JWT signature. When that URL is unset (the default) and no verification key resolver is supplied, DefaultJwtValidator silently falls back to ClientJwtValidator, which does not verify the JWT signature, algorithm, or issuer - and the broker starts with no warning or error. This is the residual of CVE-2026-33557, whose fix restored signature verification only on the path where the JWKS endpoint URL is set. Impact: A broker in this state accepts any structurally valid JWT, including "alg":"none" tokens. An unauthenticated remote attacker who can reach th...