CVE-2026-110952 in Kafka
Summary
by MITRE • 10/28/2026
A Kafka broker that authenticates clients with SASL/OAUTHBEARER using the bundled JWKS-backed validator always verifies the JWT signature, but two further checks are only performed when explicitly configured:
- The issuer (iss) claim is verified only when sasl.oauthbearer.expected.issuer is set. When it is unset, a validly-signed token carrying the expected audience is accepted regardless of which issuer minted it. - An audience (aud) claim is required only when sasl.oauthbearer.expected.audience is set. When it is unset, a validly-signed token that omits the aud claim is accepted. (A token that carries an aud claim is still rejected when no expected audience is configured.)
Both options default to unset and have been documented as optional (Importance LOW) since KIP-768 (3.1.0).
Impact: The exposure is realizable mainly in deployments whose JWKS endpoint serves signing keys for more than one issuer (a multi-tenant identity provider, an aggregated/shared JWKS, or shared signing keys): a token minted for a different issuer, or a token lacking an audience, may be accepted to authenticate — potentially as a higher-privileged principal. In a single-issuer deployment where the provider controls the iss claim and issues audience-scoped tokens, exposure is limited. The signature trust anchor remains enforced in all cases. This is distinct from CVE-2026-33557 (acceptance of unsigned/unvalidated tokens); here the signature is validated and only the issuer/audience checks are not enforced by default.
Mitigation (all affected versions, no upgrade required): Set both sasl.oauthbearer.expected.issuer (to your provider's exact iss value) and sasl.oauthbearer.expected.audience (to the audience(s) your brokers expect), per listener. Brokers that set these perform exact-match issuer/audience checks and are not affected. Both have been available since 3.1.0.
Resolution: - From Apache Kafka 4.4.0: a broker configured with a JWKS endpoint fails to start unless both sasl.oauthbearer.expected.issuer and sasl.oauthbearer.expected.audience are set (secure by default). Deployments that intentionally do not restrict the issuer and/or audience may opt out per axis with sasl.oauthbearer.allow.unverified.issuer=true and/or sasl.oauthbearer.allow.unverified.audience=true.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability in Apache Kafka’s SASL/OAUTHBEARER authentication mechanism stems from a misconfiguration of default security checks for JSON Web Tokens (JWT) when utilizing the bundled JWKS-backed validator. While the system correctly enforces cryptographic signature verification to ensure token integrity, it fails by default to validate critical identity claims: specifically the issuer and audience fields. This behavior creates a scenario where tokens that are cryptographically valid but issued by an unauthorized entity or lacking specific audience restrictions can successfully authenticate against Kafka brokers. The root cause lies in the configuration properties sasl.oauthbearer.expected.issuer and sasl.oauthbearer.expected.audience, which default to unset values. When these parameters remain unconfigured, the broker accepts any JWT that passes signature validation, provided it meets minimal structural requirements such as containing an audience claim if one is present, but ignoring tokens entirely missing the audience field or those issued by different identity providers sharing the same JWKS endpoint.
This flaw aligns with CWE-287 Improper Authentication and CWE-345 Insufficient Verification of Data Authenticity, as the system trusts a token based solely on its signature without verifying the claims that define who created it and for whom it is intended. In multi-tenant environments or deployments utilizing shared JWKS endpoints where multiple issuers publish keys to the same URL, an attacker can exploit this by obtaining a valid JWT from any of the trusted issuers. If the token lacks an audience claim or carries an issuer different from the one expected by the application logic but not explicitly configured in Kafka, it will be accepted as authentic. This allows unauthorized principals to gain access to Kafka topics and operations they should not have permission to perform, potentially leading to data exfiltration, service disruption, or lateral movement within the infrastructure if the authenticated principal has elevated privileges.
The operational impact is most severe in architectures where a single JWKS endpoint serves signing keys for multiple identity providers, such as aggregated shared services or multi-tenant platforms. In these scenarios, an attacker who compromises one tenant’s credentials can issue tokens that are validly signed by the shared key but intended for different audiences or issuers. Since Kafka does not enforce issuer or audience checks by default in older versions, these tokens bypass authentication controls entirely. Even in single-issuer deployments where the provider strictly controls the iss claim, the lack of audience verification means that any token with a correct signature and no audience field is accepted, which may violate security policies requiring explicit audience scoping to prevent cross-service token reuse attacks. This distinction is critical as it differs from vulnerabilities involving unsigned tokens; here, the cryptographic trust anchor remains intact, but the semantic validation of identity claims is absent by default configuration.
To mitigate this risk in affected versions prior to 4.4.0, administrators must explicitly configure both sasl.oauthbearer.expected.issuer and sasl.oauthbearer.expected.audience for each listener that uses SASL/OAUTHBEARER authentication. Setting these properties forces the broker to perform exact-match checks against the JWT claims, ensuring that only tokens issued by the expected identity provider and intended for the specified audience are accepted. This configuration should be applied consistently across all brokers in the cluster to prevent any node from accepting improperly scoped tokens. For deployments using Apache Kafka 4.4.0 or later, the default behavior has been changed to require these configurations before a broker with a JWKS endpoint can start, effectively making secure defaults mandatory unless explicitly opted out via sasl.oauthbearer.allow.unverified.issuer=true or sasl.oauthbearer.allow.unverified.audience=true. Organizations should audit their Kafka configurations immediately and update them to enforce strict issuer and audience validation to align with industry best practices for OAuth2/OIDC integration as outlined in ATT&CK techniques related to initial access via compromised credentials or token manipulation.