Docker Hub: transferir um token não transfere o conhecimento do segredo

A Docker revelou a CVE-2026-105445, corrigida em 30 de setembro de 2026, no fluxo de conversão de uma conta pessoal do Docker Hub em organização.[2] O processo transferia tokens pessoais para o proprietário indicado sem revogar ou trocar os segredos, e esse proprietário não precisava consentir.[2] É um erro de identidade com uma lição útil para qualquer backend: mudar o dono no banco não muda quem conhece a credencial.

O que muda para quem desenvolve

Um atacante podia criar um token na própria conta, convertê-la em organização indicando uma vítima e continuar usando o segredo conhecido, agora autenticando no registry como essa vítima, dentro do escopo concedido.[2] O impacto potencial incluía baixar, publicar e excluir imagens em repositórios acessíveis à vítima.[2]

Esse alcance importa para pipelines: a integridade da imagem publicada deve fazer parte da revisão de segurança, não apenas a proteção do login humano. A falha não dava acesso à interface web nem permitia alterar senha, e-mail ou autenticação de dois fatores.[2] Chamar o caso de tomada completa de todos os serviços esconderia a fronteira real do problema.

Minha leitura de arquitetura é que a titularidade e o material secreto precisam de ciclos de vida explícitos. Uma transferência administrativa deve decidir o destino das credenciais existentes, em vez de carregar permissões e segredos por conveniência.

Como aplicar

Inventarie as credenciais usadas para publicar imagens. Para cada uma, registre responsável, finalidade, escopo, consumidores e procedimento de substituição. Não copie o valor do token para planilhas ou documentação. A Docker recomenda tokens de acesso de organização para automações pertencentes à organização e revogação de tokens desconhecidos ou desnecessários.[2]

Se houver notificação de exposição, confira quais pipelines dependem dos tokens identificados e substitua essas dependências de forma coordenada. Os afetados receberam avisos em 2 de outubro, e os tokens identificados foram desativados em 8 de outubro, salvo exceções solicitadas pelos titulares.[2]

Para testar um produto próprio, monte um cenário com dois usuários fictícios e uma credencial sem acesso a dados reais. Transfira um recurso entre eles e verifique se a credencial antiga continua válida. O critério de aceite deve refletir a política escolhida: consentimento do novo responsável, revogação ou substituição do segredo e registro auditável da operação. Teste também falhas entre essas etapas, para não deixar a transferência pela metade.

Cuidados e limites

A Docker afirma não ter encontrado evidência de exploração após revisar conversões e aproximadamente 304 mil publicações de imagens.[2] A própria investigação ressalva que logs mostram utilização do token, não sua mera existência, razão para considerar os tokens transferidos potencialmente expostos.[2]

Não confunda ausência de evidência com uma garantia abstrata de segurança. Por outro lado, evite revogar indiscriminadamente toda credencial sem mapear os consumidores. A resposta útil combina contenção, continuidade e conferência do que foi publicado.

Fonte

[2] Fonte: Docker Blog