Quick answers
- Is CVE-2026-110985 exploited in the wild?
- No. Junglewise Threat Intelligence has no report of CVE-2026-110985 being exploited in the wild.
- How severe is CVE-2026-110985?
- Informational severity, published 28 October 2026.
- Which products and versions are affected?
- Apache Kafka before 4.2.2, 4.3.1, and 4.4.0.
- Is there a fix for CVE-2026-110985?
- Yes: fixed in Apache Kafka 4.2.2, 4.3.1, 4.4.0. Until then: Set sasl.oauthbearer.jwks.endpoint.url for every listener/mechanism that uses OAuthBearerValidatorCallbackHandler, or configure a custom sasl.oauthbearer.jwt.validator.class that verifies signatures. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
- How is CVE-2026-110985 attacked?
- It is attacked over the network, in a software library.
- Am I affected by CVE-2026-110985?
- Check whether you run Apache Kafka at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.
How to fix
- Fixed in: Apache Kafka 4.2.2, 4.3.1, 4.4.0
Set sasl.oauthbearer.jwks.endpoint.url for every listener/mechanism that uses OAuthBearerValidatorCallbackHandler, or configure a custom sasl.oauthbearer.jwt.validator.class that verifies signatures.
Technical details
When SASL/OAUTHBEARER is enabled with the DefaultJwtValidator and no JWKS endpoint URL is configured, the broker silently falls back to ClientJwtValidator, which does not verify JWT signatures, algorithms, or issuers. An unauthenticated remote attacker can send a forged or structurally valid JWT (including "alg":"none" tokens) to any exposed listener and gain full cluster access. The vulnerability is fixed in Kafka 4.2.2, 4.3.1, and 4.4.0 by failing startup with a ConfigException instead of running insecurely.
Affected products
- Apache Kafka before 4.2.2, 4.3.1, and 4.4.0
Timeline
- 2026-10-28: disclosed