Apache Kafka EUVD-2026-112207

Exploitation requires a Kafka broker configured with SASL/OAUTHBEARER using OAuthBearerValidatorCallbackHandler and the default DefaultJwtValidator (sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator), where sasl.oauthbearer.jwks.endpoint.url is left unset (the default) AND no custom verification key resolver is supplied - this combination causes the silent fallback to the non-verifying ClientJwtValidator. The attacker must have network reachability to the affected OAUTHBEARER listener. Brokers that set sasl.oauthbearer.jwks.endpoint.url, or configure a signature-verifying validator class, verify JWT signatures and are NOT affected; this is the key limiting factor, since the vulnerability depends on this specific OAUTHBEARER-without-JWKS-URL configuration rather than on any default Kafka install. On versions 4.2.2, 4.3.1, and 4.4.0 and later, a broker that would fall back to ClientJwtValidator refuses to start (ConfigException), so the vulnerable state cannot exist there.

No official CVSS score or vector is provided (CVSS: N/A), and no EPSS probability, KEV listing, or PoC reference is present in the input, so the quantitative exploitation signals are absent and cannot be compared. The strongest available signal is the vuln.today Decision label of 'this_week' combined with the vendor's own technical description, which together describe a complete authentication bypass: when SASL/OAUTHBEARER is enabled with DefaultJwtValidator and no JWKS endpoint URL (the default) and no custom verification key resolver, the broker silently falls back to ClientJwtValidator and verifies no signature, algorithm, or issuer, accepting even 'alg':'none' tokens. On an affected broker this is a critical, trivially exploitable flaw - an unauthenticated remote attacker who can reach the listener can forge a token for any principal including superusers and take over the cluster. The important qualifier is that this is config-dependent, not universal: only brokers that enable OAUTHBEARER validation WITHOUT a JWKS endpoint URL and without a custom resolver are affected, so real-world exposure depends on deployment configuration rather than on the mere presence of Kafka. This is a genuine high-priority issue for the affected configuration subset, not a high-CVSS-but-low-real-risk case; however, the absence of EPSS/KEV/PoC data means there is no evidence of active or at-scale exploitation at time of analysis, so prioritization rests on severity and ease of exploitation rather than observed attacks.

An attacker with network reachability to a Kafka broker whose OAUTHBEARER listener runs DefaultJwtValidator without a configured JWKS endpoint URL crafts a structurally valid JWT (for example one using 'alg':'none') asserting a configured superuser principal. Because the fallback ClientJwtValidator performs no signature, algorithm, or issuer verification, the broker accepts the forged token and grants full cluster access. No public exploit was identified at time of analysis, and the trigger mechanism (forging a JWT) is described directly in the vendor advisory.