CVE-2026-35554

In Apache Kafka, the default JWT validator class (`DefaultJwtValidator`) accepts any JWT token without validating its signature, issuer, or audience. An attacker can generate a token from any issuer with any username, and the broker will accept it.

Incorrect operator (CWE-480) in the FetchSnapshot RPC handler in Apache Kafka from 2.8.0 before 4.2.2, and from 4.3.0 before 4.3.2, allows an authenticated attacker with CLUSTER_ACTION privilege to cause a denial of service. Exploitation occurs via a crafted FetchSnapshotRequest with an empty topics array or a topic with no partitions, terminating the controller process.

A vulnerability in Apache Kafka allows an authenticated producer with Write permission on a topic to declare a decompressed body size of up to about 2 GiB in a compressed record, forcing a buffer allocation and causing an OutOfMemoryError. This can crash broker request-handler threads, consumers, and permanently stop the log-cleaner thread on compacted topics.

An authenticated Kafka principal with no authorization grants can make a broker read a file or environment variable from the broker host and return its contents. An IncrementalAlterConfigs or AlterConfigs request targeting a BROKER resource reaches configuration validation before any authorization check, and configuration-variable resolution (${file:...}, ${env:...}) bypasses the config-providers allowlist added as mitigation for CVE-2024-31141.

Several Apache Kafka deserialization paths read a size or count field from input data and use it directly to allocate an array, collection, or byte buffer without checking the bytes actually available. A small crafted input can declare a very large size and force a multi-gigabyte allocation, causing an OutOfMemoryError. Affected paths include ProcessorRecordContext, ChangedDeserializer, CombinedKeySchema, ProcessorMetadata, and AssignmentInfo in Kafka Streams, and ListDeserializer in the clients library.

A vulnerability in Apache Kafka's code-generated readers for flexible protocol versions reads a tagged-field count declared by the sender and retains a RawTaggedField object for each unknown field. The count was bounded only by the outer request frame size, not by remaining buffer bytes or a fixed cap, allowing a modest request to declare tens of millions of tagged fields and force one object allocation per field. Flexible request headers are parsed before authorization, so the amplification applies pre-authentication.

Apache Kafka's code-generated protocol readers pre-size an array's collection from the element count declared by the sender, checked only against the bytes remaining in the request buffer (assuming about one byte per element). For a keyed array the reader 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 affects all Kafka API types with an array field.

The vulnerability affects the broker-side PushTelemetry API (KIP-714) in Apache Kafka, which validates only the compressed size of a client's metrics payload against telemetry.max.bytes before decompressing it without any limit on the decompressed output size. A small, highly compressible payload can expand to hundreds of megabytes of broker heap, causing an OutOfMemoryError.

In an Apache Kafka broker using SASL/OAUTHBEARER with the default validator (DefaultJwtValidator), when sasl.oauthbearer.jwks.endpoint.url is unset and no custom verification key resolver is supplied, the validator silently falls back to ClientJwtValidator, which does not verify the JWT signature, algorithm, or issuer. The broker starts without any warning and accepts any structurally valid JWT, including "alg":"none" tokens. This is the residual of CVE-2026-33557, whose fix restored signature verification only on the path where the JWKS endpoint URL is set.

An Apache Kafka broker authenticating clients via SASL/OAUTHBEARER with the bundled JWKS-backed validator always verifies the JWT signature, but does not enforce the issuer (iss) or audience (aud) claims unless sasl.oauthbearer.expected.issuer and sasl.oauthbearer.expected.audience are explicitly configured. As a result, a validly signed token from a different issuer or lacking an aud claim may be accepted. Exposure mainly affects deployments whose JWKS endpoint serves signing keys for multiple issuers or shared signing keys.