CVE-2026-110985
Low risk· EPSS 2%Exploitation Probability (EPSS)
Low risk2th percentile - higher than 2% of all known CVEs
Summary
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.
Risk Assessment
An unauthenticated remote attacker who can reach the listener can forge a JWT asserting any principal, including configured superusers, and gain full access to the cluster. Only brokers that enable SASL/OAUTHBEARER validation without a JWKS endpoint URL (and without a custom verification key resolver) are affected.
Recommendation
For every listener/mechanism using OAuthBearerValidatorCallbackHandler, set sasl.oauthbearer.jwks.endpoint.url or configure a signature-verifying sasl.oauthbearer.jwt.validator.class. From Apache Kafka 4.2.2, 4.3.1, and 4.4.0, a broker that would fall back to the non-verifying ClientJwtValidator fails to start with a ConfigException.
Other vulnerabilities in Apache Kafka
See all- CVE-2026-33557Critical
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.
- CVE-2026-83525Low risk· EPSS 8%
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.
- CVE-2026-114349Low risk· EPSS 16%
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.
- CVE-2026-112375Low risk· EPSS 13%
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.
- CVE-2026-111551Low risk· EPSS 13%
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.
- CVE-2026-111115Low risk· EPSS 15%
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.
- CVE-2026-111108Low risk· EPSS 19%
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.
- CVE-2026-111073Low risk· EPSS 10%
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.
- CVE-2026-110952Low risk· EPSS 2%
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.
- CVE-2026-41115Medium
An improper authorization vulnerability has been identified in Apache Kafka. The CONSUMER_GROUP_DESCRIBE (69) API validates the DESCRIBE operation on the GROUP resource instead of the READ operation as documented. This can result in misconfigured ACLs and unintended security postures.
Original NVD description (English source)
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 the listener can forge a token asserting any principal - including configured superusers - and gain full access to the cluster. Only brokers that enable SASL/OAUTHBEARER validation without a JWKS endpoint URL (and without a custom verification key resolver) are affected; brokers that set the URL verify signatures and are not affected. Unlike CVE-2026-110952 (issuer/audience not enforced by default), here no signature is verified at all. Mitigation (all affected versions, no upgrade required): Set sasl.oauthbearer.jwks.endpoint.url for every listener/mechanism that uses OAuthBearerValidatorCallbackHandler, or configure a signature-verifying sasl.oauthbearer.jwt.validator.class. Resolution: From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: a broker that would fall back to the non-verifying ClientJwtValidator fails to start with a ConfigException instead of running without signature verification (secure by default).
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

