Uma identidade de armazenamento com permissão de leitura não deveria alcançar chaves de criptografia nem credenciais administrativas dos hosts. Na CVE-2026-50152, essa separação falhou dentro do Ceph Monitor: qualquer entidade CephX com a capacidade mon allow r podia enviar uma assinatura preparada e receber todo o config-key store do cluster.
A Red Hat atribui à falha CVSS 3.1 preliminar de 8,2, com vetor CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L. O atacante precisa alcançar a rede do cluster e possuir uma chave CephX válida com baixo privilégio, mas não depende de interação de outra pessoa. A documentação do Ceph afirma que uma única mensagem MMonSubscribe preparada retorna os segredos de forma determinística.
Quem está exposto e quais versões corrigem
O advisory do Ceph declara todas as versões anteriores vulneráveis. As correções estão nas linhas ainda suportadas, Tentacle 20.2.4 ou posterior e Squid 19.2.6 ou posterior, ambas publicadas em 19 de agosto de 2026. Versões antigas e fora de suporte não receberam uma versão corrigida listada, por isso permanecer nelas não é uma estratégia de mitigação.
- Condição de acesso: conectividade com o cluster e uma identidade CephX válida
- Capacidade suficiente no sistema vulnerável: mon allow r
- Interação de usuário: nenhuma
- Versões corrigidas: Tentacle 20.2.4+ e Squid 19.2.6+
- Versões anteriores: tratadas como vulneráveis pelo projeto Ceph
- CWE: 862, ausência de autorização
Como uma assinatura vira leitura do cofre
O Monitor processa assinaturas para diferentes mapas e canais internos. Antes da correção, a checagem genérica de leitura do Monitor também aceitava assinaturas cujo nome começava com kv:, prefixo usado pelo config-key store. Assim, possuir mon allow r era suficiente para atravessar uma autorização que deveria ser específica do repositório de segredos.
} else if (p->first.starts_with("kv:")) {
if (!s->is_capable("config-key", MON_CAP_R)) {
dout(5) << __func__ << " " << op->get_req()->get_source_inst()
<< " not enough caps for " << p->first << " -- dropping"
<< dendl;
continue;
}
}O patch move a decisão para antes do registro da assinatura e descarta a solicitação quando falta a capacidade config-key. Esse detalhe importa em revisão de código: checar autorização somente quando o dado é entregue pode deixar outros caminhos de assinatura ou efeitos colaterais acessíveis. O projeto confirmou o vetor por MMonSubscribe, mas não publicou os bytes da mensagem. Por isso, não inventamos um payload que pareça funcional sem ser verificável.
O conteúdo do config-key muda o impacto
O config-key store não guarda apenas configuração inofensiva. O Ceph lista passphrases LUKS dos OSDs, segredos do dashboard e credenciais de gateways. Em clusters administrados por cephadm, ele também pode conter a chave SSH privada usada para autenticar em todos os hosts gerenciados. Uma leitura indevida deixa de ser apenas vazamento quando essa chave permite obter acesso root nas máquinas do cluster.
O CVSS descreve a condição base, mas o raio de ação vem da configuração. Um cluster sem cephadm tem uma cadeia diferente de um ambiente em que a mesma chave SSH administra todos os nós. O inventário de segredos, a reutilização de credenciais, o alcance de rede e os registros de uso precisam entrar na análise de impacto.
Como validar exposição sem ler os segredos
A primeira triagem não precisa reproduzir a extração. Confirme as versões efetivamente executadas pelos daemons e liste somente as capacidades de Monitor atribuídas às entidades. O comando abaixo descarta o campo de chave no filtro e mostra apenas nome e mon cap. A saída ainda deve ser tratada como informação administrativa e executada em uma sessão controlada.
ceph versions --format json-pretty
ceph auth ls --format json |
jq -r '.auth_dump[]
| select(.caps.mon? != null)
| [.entity, .caps.mon]
| @tsv'Procure mon allow r, combinações como allow rw ou allow rwx, allow * e perfis que resultem em leitura. Não trate a ausência de uma identidade óbvia como prova de segurança: contas de serviço, clientes de CephFS, integrações de backup e credenciais antigas podem carregar essa capacidade. A confirmação dinâmica deve ocorrer apenas em laboratório isolado ou durante pentest autorizado, com autorização explícita para manipular o protocolo do Monitor.
Atualizar fecha a leitura, mas não invalida o que vazou
Instalar Tentacle 20.2.4 ou Squid 19.2.6 bloqueia novas assinaturas sem a capacidade específica, mas não revoga um segredo já obtido. O próprio projeto recomenda rotação imediata da chave SSH do cephadm em clusters administrados por ele. Para os demais segredos, a orientação é avaliar exposição e seguir o procedimento do produto ou da integração correspondente, preservando evidências antes de alterar o ambiente quando houver suspeita de abuso.
- Atualizar todos os daemons e confirmar que nenhum Monitor permanece em versão vulnerável
- Inventariar identidades com qualquer capacidade de leitura no Monitor e remover acessos desnecessários
- Rotacionar a chave SSH do cephadm e distribuir a nova chave pelo procedimento oficial
- Mapear passphrases de OSD, segredos do dashboard e credenciais de gateway armazenados no config-key
- Revisar logs de autenticação, conexões ao Monitor e acessos SSH incompatíveis com a operação esperada
- Preservar evidências e ampliar a investigação para todos os hosts alcançáveis por credenciais expostas
- Migrar clusters fora de suporte para uma linha que receba correções de segurança
O que essa falha acrescenta ao pentest de infraestrutura
Permissão de leitura não é sinônimo de baixo impacto. Em sistemas distribuídos, um principal aparentemente restrito pode consultar metadados, assinar canais internos ou alcançar cofres usados pela camada de controle. Um pentest de Ceph precisa testar as capacidades efetivas de cada identidade, os limites do protocolo do Monitor e o destino dos segredos administrativos. A pergunta útil não é apenas o que a conta pode ler. É quais novas identidades ela consegue assumir depois dessa leitura.