CVE-2026-110985 in Kafka
Summary
by MITRE • 10/28/2026
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).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
This vulnerability represents a critical authentication bypass in Apache Kafka brokers configured for SASL/OAUTHBEARER, stemming from an insecure fallback mechanism within the DefaultJwtValidator class. The core technical flaw lies in how the validator handles missing configuration parameters. When the sasl.oauthbearer.jwks.endpoint.url property is not explicitly set and no custom verification key resolver is provided, the system silently defaults to ClientJwtValidator instead of failing securely or requiring explicit validation logic. This silent fallback means that signature verification, algorithm enforcement, and issuer checks are completely disabled without any warning or error message during broker startup. Consequently, the broker operates under a false sense of security while actually accepting tokens with no cryptographic integrity guarantees.
The operational impact is severe, allowing unauthenticated remote attackers to gain full control over the Kafka cluster if they can reach the listener port. Because signature verification is bypassed, an attacker can forge any structurally valid JSON Web Token (JWT), including those using the alg:none algorithm which explicitly indicates no digital signature. By crafting a token that asserts arbitrary principal names, including those mapped to configured superusers or administrative roles, the attacker achieves full authentication and authorization privileges within the cluster. This effectively nullifies the security boundary provided by SASL/OAUTHBEARER, enabling data exfiltration, topic manipulation, or complete cluster compromise depending on the permissions associated with the forged identity.
This issue is a residual effect of CVE-2026-33557, where previous remediation efforts only addressed signature verification for paths where the JWKS endpoint URL was configured. The oversight left the default configuration path vulnerable to token forgery. Unlike related issues such as CVE-2026-110952 which involved insufficient enforcement of issuer and audience claims, this vulnerability is more fundamental because it removes all cryptographic validation entirely. This aligns with CWE-347 Improper Verification of Cryptographic Signature and CWE-287 Improper Authentication, reflecting a failure to ensure the authenticity and integrity of security tokens before granting access.
Mitigation strategies focus on ensuring that signature verification is always enforced through explicit configuration rather than relying on default behaviors. Administrators must set sasl.oauthbearer.jwks.endpoint.url for every listener or mechanism utilizing OAuthBearerValidatorCallbackHandler. Alternatively, configuring a custom sasl.oauthbearer.jwt.validator.class that implements proper cryptographic validation can resolve the issue without requiring an upgrade. These steps ensure that tokens are verified against known public keys before authentication is granted, preventing the silent fallback to insecure verification modes.
The resolution was implemented in Apache Kafka versions 4.2.2, 4.3.1, and 4.4.0 by modifying the startup logic of DefaultJwtValidator. In these updated releases, if the conditions that previously triggered a fall back to ClientJwtValidator are met, the broker now throws a ConfigException during initialization rather than starting with signature verification disabled. This change enforces a secure-by-default posture where explicit configuration is required for any non-standard validation behavior, ensuring that brokers do not operate in an insecure state due to missing or ambiguous settings.