Apache Kafka EUVD-2026-112209

Exploitation requires a broker using SASL/OAUTHBEARER with the bundled JWKS-backed validator where sasl.oauthbearer.expected.issuer and/or sasl.oauthbearer.expected.audience are left at their default (unset), AND a JWKS endpoint that serves signing keys for more than one issuer - a multi-tenant identity provider, an aggregated/shared JWKS, or shared signing keys. The attacker must be able to obtain a validly-signed token minted for a different issuer trusted by that JWKS, or a validly-signed token that omits the aud claim (a token that carries an aud claim is still rejected when no expected audience is configured). Limiting factors that reduce real-world risk: the JWT signature trust anchor is enforced in all cases, so unsigned/invalid tokens are not accepted; single-issuer deployments where the provider controls the iss claim and issues audience-scoped tokens have limited exposure; brokers that set both expected.issuer and expected.audience perform exact-match checks and are not affected (available since 3.1.0); and from Kafka 4.4.0 a JWKS-configured broker fails to start unless both are set or explicitly opted out.

No CVSS score or vector is provided in the input, so attack-vector/complexity/privilege signals must be inferred from the description rather than read from a vendor-assigned metric - treat the assessed vector below as analyst-derived, not authoritative. The vuln.today decision label is 'this_month' (prioritized but not act_now/emergency), and there is no CISA KEV listing, no EPSS probability, and no PoC or exploit reference in the data, so there is no public exploit identified at time of analysis and no evidence of active or widespread exploitation. The core mitigating factor is that this is a configuration- and deployment-dependent weakness (CWE-345): the signature trust anchor is always enforced, and the issuer/audience bypass is only reachable when sasl.oauthbearer.expected.issuer and/or sasl.oauthbearer.expected.audience are left at their documented default (unset) AND the JWKS endpoint serves signing keys for more than one issuer (multi-tenant IdP, aggregated/shared JWKS, or shared signing keys). In a single-issuer deployment where the provider controls the iss claim and issues audience-scoped tokens, exposure is limited. Therefore this reads as a genuine but conditional authentication-robustness issue rather than a broad high-risk emergency: high real impact where the multi-issuer precondition holds, low exposure otherwise. The optional-by-default design predates this CVE (documented LOW importance since KIP-768 / 3.1.0), which is likely why Apache treats it as a hardening/secure-default change rather than an urgent patch.

In an environment where Kafka brokers authenticate clients via SASL/OAUTHBEARER against a shared or multi-tenant JWKS that signs tokens for several issuers, and the brokers have not set the expected issuer/audience, an attacker obtains a validly-signed token minted for a different issuer (or a token with no aud claim) and presents it to the broker, which accepts it and maps it to a principal - potentially a higher-privileged one. No public exploit code is identified at time of analysis; exploitation requires the attacker to already be able to obtain such a signed token from an issuer trusted by the same JWKS.