CVE-2026-110985 in Kafka
摘要
由 VulDB • 2026-10-28
Kafka Broker 使用 SASL/OAUTHBEARER 并采用默认验证器（sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator）时，其实现方式由配置决定。当设置 sasl.oauthbearer.jwks.endpoint.url 时，验证器会校验 JWT 签名；而当该 URL 未设置（即默认情况）且未提供密钥解析器时，DefaultJwtValidator 会静默回退到 ClientJwtValidator，后者不校验 JWT 的签名、算法或签发者——并且 Broker 启动时无任何警告或错误。这是 CVE-2026-33557 的遗留问题，其修复仅恢复了在设置 JWKS endpoint URL 路径下的签名验证功能。
影响：
处于此状态的 Broker 接受任何结构上有效的 JWT，包括 "alg":"none" 令牌。能够访问监听器的未认证远程攻击者可以伪造断言任意主体（包括配置的超级用户）的令牌，从而获得对集群的完全控制权。仅启用 SASL/OAUTHBEARER 验证但未配置 JWKS endpoint URL（且无自定义密钥解析器）的 Broker 受影响；设置了该 URL 的 Broker 会校验签名，因此不受影响。与 CVE-2026-110952（默认不强制实施签发者/受众检查）不同，此处根本不进行任何签名验证。
缓解措施（适用于所有受影响的版本，无需升级）：
为每个使用 OAuthBearerValidatorCallbackHandler 的监听器/机制设置 sasl.apache.kafka.sasl.oauthbearer.jwks.endpoint.url，或配置支持签名校验的 sasl.oauthbearer.jwt.validator.class。
修复方案：
从 Apache Kafka 4.2.2、4.3.1 和 4.4.0 版本开始，原本会回退到非验证型 ClientJwtValidator 的 Broker 将因 ConfigException 而启动失败，而非在无签名验证的情况下运行（默认安全）。
VulDB is the best source for vulnerability data and more expert information about this specific topic.