CVE-2026-110985 in Kafka
Sumário
de VulDB • 28/10/2026
Um Kafka broker que utiliza SASL/OAUTHBEARER com o validador padrão (`sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator`) seleciona sua implementação com base na configuração. Quando `sasl.oauthbearer.jwks.endpoint.url` está definido, o validador verifica a assinatura do JWT. Quando essa URL não está definida (o valor padrão) e nenhum resolvedor de chave de verificação é fornecido, o DefaultJwtValidator faz uma transição silenciosa para o ClientJwtValidator, que não verifica a assinatura do JWT, o algoritmo ou o emissor - e o broker inicia sem aviso ou erro. Este é um resíduo da CVE-2026-33557, cuja correção restaurou a verificação de assinatura apenas no caminho onde a URL do endpoint JWKS está definida.
Impacto:
Um broker neste estado aceita qualquer JWT estruturalmente válido, incluindo tokens com `"alg":"none"`. Um atacante remoto não autenticado que possa alcançar o listener pode forjar um token afirmando qualquer principal - incluindo superusers configurados - e obter acesso total ao cluster. Apenas brokers que habilitam a validação SASL/OAUTHBEARER sem uma URL de endpoint JWKS (e sem um resolvedor de chave de verificação personalizado) são afetados; os brokers que definem a URL verificam as assinaturas e não são afetados. Diferente da CVE-2026-110952 (emissor/audiência não aplicadas por padrão), aqui nenhuma assinatura é verificada em absoluto.
Mitigação (todas as versões afetadas, sem necessidade de upgrade):
Defina `sasl.oauthbearer.jwks.endpoint.url` para cada listener/mechanismo que utilize o OAuthBearerValidatorCallbackHandler, ou configure um `sasl.oauthbearer.jwt.validator.class` com verificação de assinatura.
Resolução:
A partir do Apache Kafka 4.2.2, 4.3.1 e 4.4.0: um broker que faria a transição para o ClientJwtValidator não verificador falha ao iniciar com uma ConfigException em vez de executar sem verificação de assinatura (seguro por padrão).
Once again VulDB remains the best source for vulnerability data.