Uma falha no processo de conversão de contas do Docker Hub em organizações permitia que um token de acesso pessoal permanecesse válido depois de ser transferido para a identidade de outro usuário. Identificada como CVE-2026-105445 e classificada como crítica, com 9,4 no CVSS 4.0, a vulnerabilidade foi corrigida pela Docker em 30 de setembro de 2026. A empresa afirma não ter encontrado evidências de exploração maliciosa.
A descoberta chama atenção por uma razão específica: o Docker Hub funciona como fonte de imagens usadas diariamente por desenvolvedores, equipes de infraestrutura e pipelines automatizados. Uma publicação indevida sob o nome de um fornecedor ou projeto legítimo poderia colocar código não autorizado no caminho de quem confia naquele repositório. Essa consequência era tecnicamente possível, mas não há confirmação pública de que tenha ocorrido neste caso.
Como um token passava a representar outra identidade
O problema surgiu na funcionalidade que converte uma conta pessoal em organização, preservando o nome dos repositórios e os endereços usados para baixar imagens. Desde 26 de agosto de 2024, o processo também transferia os personal access tokens (PATs) da conta convertida para o usuário indicado como novo proprietário. A transferência mudava o registro de titularidade do token, mas não revogava nem substituía seu segredo. Tampouco exigia a confirmação do novo proprietário.
Segundo a Docker, um invasor autenticado poderia criar sua própria conta e um PAT, convertê-la em organização e indicar uma vítima como proprietária. O token continuaria conhecido pelo invasor, embora passasse a autenticar no registry com a identidade e as permissões disponíveis ao usuário indicado. Dependendo do escopo concedido, isso permitiria baixar, publicar ou excluir imagens em repositórios acessíveis à vítima, inclusive de organizações às quais ela pertencesse.
Há uma diferença importante entre essa capacidade e assumir completamente uma conta. A falha não concedia acesso à interface web do Docker Hub, nem permitia modificar senha, e-mail ou configurações de autenticação de dois fatores. O risco estava concentrado nas operações autenticadas do registry, justamente onde imagens são distribuídas e consumidas.
Notícias Relacionadas
Do registro de imagens ao ambiente de produção
O cenário de maior preocupação envolve imagens que parecem ter sido publicadas pelo mantenedor legítimo, mas cujo conteúdo foi substituído ou adulterado. Em uma organização que executa automaticamente a versão mais recente de uma imagem, a confiança no nome do repositório pode fazer com que a alteração alcance ambientes de testes e produção. O risco aumenta quando processos de implantação não verificam a assinatura ou a identidade imutável do artefato consumido.
Isso não significa que toda imagem hospedada no Docker Hub estivesse vulnerável, nem que fosse possível publicar arbitrariamente em qualquer repositório. A exploração dependia do fluxo de conversão de conta, da identidade indicada como proprietária e das permissões efetivas do token transferido. Também não se tratava de uma falha do Docker Engine instalado nos servidores, mas de um problema no serviço de identidade e autorização do Docker Hub.
A Docker informou ter analisado as conversões realizadas desde agosto de 2024, cruzando registros de autenticação, uso do Hub e dados de tokens. A investigação incluiu aproximadamente 304 mil operações de publicação realizadas com tokens transferidos. A empresa não encontrou publicações em contas de terceiros sem relação com o processo legítimo e relatou que a análise estática de imagens públicas consideradas de maior risco não revelou malware ou adulteração. Ainda assim, reconheceu uma limitação: tokens transferidos que nunca foram utilizados não aparecem nos logs de operações do registry.
Correção aplicada e verificações recomendadas
O problema foi comunicado à Docker em 30 de setembro pelos pesquisadores Peter Molnar e Krisztian Hozak. A correção entrou em produção menos de quatro horas depois, impedindo a transferência de PATs durante novas conversões. Em 2 de outubro, a empresa notificou os usuários e responsáveis por organizações potencialmente expostos. Em 8 de outubro, desativou os tokens transferidos identificados, com exceção daqueles cujos proprietários solicitaram expressamente sua manutenção.
Para os usuários notificados, a recomendação é revisar os PATs associados à conta, revogar credenciais desconhecidas ou desnecessárias e verificar a atividade de publicação nos repositórios relevantes. A própria Docker orienta que automações de organizações utilizem tokens de organização em vez de credenciais pessoais. Quem não recebeu a notificação, segundo a empresa, não foi exposto por esse fluxo específico e não precisa realizar uma ação corretiva relacionada à CVE.
Equipes que dependem de imagens de terceiros também podem reduzir o impacto de eventuais adulterações usando digests imutáveis em implantações, verificando assinaturas e procedência dos artefatos, restringindo permissões de publicação e monitorando alterações inesperadas em imagens e pipelines. Essas medidas são recomendações gerais de segurança da cadeia de software, não uma indicação de comprometimento comprovado pela CVE-2026-105445.
O episódio deixa uma questão concreta para gestores de plataformas e equipes de desenvolvimento: a segurança de um repositório depende também de como credenciais mudam de proprietário. Uma falha discreta na gestão dessa titularidade pode produzir permissões que o usuário legítimo jamais concedeu, mesmo sem qualquer comprometimento de sua senha.
Be the first to comment