Live › vulnerability › CVE-2026-110952
Go to dashboardApache Kafka brokers using the bundled JWKS-backed SASL/OAUTHBEARER validator verify the token signature but do not check the issuer or audience claims unless sasl.oauthbearer.expected.issuer and sasl.oauthbearer.expected.audience are set. A token signed by another issuer sharing the same JWKS, or a token without an aud claim, can be accepted and may authenticate as a higher-privileged principal.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-28 17:34 UTC. All times on this page are UTC.
Kafka clusters that authenticate clients with SASL/OAUTHBEARER through the bundled JWKS-backed validator and leave the expected issuer or expected audience unset. Exposure is highest when the JWKS endpoint serves signing keys for multiple issuers, such as a multi-tenant identity provider or a shared JWKS. Single-issuer deployments where the provider controls iss and issues audience-scoped tokens face limited exposure, and clusters not using OAUTHBEARER can skip it.
No product ranges from the sources yet.
sasl.oauthbearer.expected.issuer and sasl.oauthbearer.expected.audience on each OAUTHBEARER listener; if either is missing, the broker is exposed.kafka-broker-api-versions.sh --version or the Kafka distribution; affected versions are those with the bundled JWKS validator from 3.1.0 onward.sasl.oauthbearer.expected.issuer to the provider's exact iss value and sasl.oauthbearer.expected.audience to the audience brokers expect, per listener; this works on all affected versions.4.4.0 or later, where a JWKS-configured broker refuses to start unless both options are set.sasl.oauthbearer.allow.unverified.issuer=true and/or sasl.oauthbearer.allow.unverified.audience=true.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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:
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:
This page as .md · .json · in your agent: get_signal("CVE-2026-110952")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.