Docker corrige falha crítica que permitia publicar imagens em contas de terceiros
A Docker corrigiu uma vulnerabilidade crítica no Docker Hub que poderia permitir que usuários executassem ações em repositórios pertencentes a outras contas. Identificada como CVE-2026-105445 e apelidada de GhostPat, a falha recebeu nota 9,4 na escala CVSS 4.0. Entre as operações possíveis estavam baixar, publicar e excluir imagens de contêineres.
O problema afetava o processo de conversão de uma conta pessoal do Docker Hub em uma organização. Para manter um nome de usuário ou namespace, a plataforma permite transformar a conta e indicar outra conta já existente como proprietária. O erro estava na forma como os tokens de acesso pessoal, conhecidos como PATs, eram tratados durante essa mudança.
Esses tokens funcionam como credenciais para autenticar operações no registro de imagens, sem exigir o uso direto da senha. Na conversão, a propriedade associada aos PATs era alterada, mas os valores dos tokens continuavam válidos. Assim, quem havia criado um token antes da mudança podia continuar usando-o, agora com as permissões vinculadas à conta indicada como dona da organização.
Na prática, uma pessoa poderia criar um token em uma conta sob seu controle, convertê-la em organização e designar outra conta como proprietária. Depois, o token ainda ativo permitiria realizar operações no Docker Hub com a identidade e as permissões desse novo proprietário. A vítima não precisava aceitar a transferência e, segundo os pesquisadores, não recebia uma notificação, embora a interface informasse desde pelo menos agosto de 2024 que um e-mail seria enviado.
O alcance das ações dependia das permissões concedidas ao token e do acesso da conta proprietária. Entre os riscos estavam publicar imagens em um namespace legítimo, acessar repositórios privados ou remover imagens. Esse cenário era especialmente preocupante para a cadeia de suprimentos de software: uma imagem maliciosa publicada como se fosse de um desenvolvedor ou de uma organização confiável poderia ser incorporada a projetos e sistemas de terceiros.
A brecha, porém, não permitia assumir por completo uma conta do Docker Hub. A exploração se limitava às operações no registro de imagens e não dava acesso à interface web, nem permitia trocar senhas ou endereços de e-mail ou desativar a autenticação de dois fatores.
A vulnerabilidade foi descoberta por Peter Molnar e Krisztian Hozak, da mptrdev.com. Os pesquisadores reproduziram o problema duas vezes com contas de teste autorizadas. Nos testes, conseguiram autenticar-se no registro usando a identidade de outra conta, criar e publicar imagens no namespace dela, enviar conteúdo para uma organização da qual ela participava e acessar repositórios privados.
A Docker afirma ter corrigido a falha em 30 de setembro de 2026, menos de quatro horas após receber o relato. Como o problema estava no próprio serviço Docker Hub, a correção foi aplicada pela empresa, sem que usuários precisassem instalar uma atualização. O comunicado de segurança foi divulgado em 12 de outubro. A falha existia desde 26 de agosto de 2024.
Depois da correção, a empresa analisou os registros da plataforma em busca de sinais de exploração. A investigação considerou conversões de contas, autenticações, uso de tokens e operações no registro, incluindo cerca de 304 mil publicações feitas com tokens transferidos. De acordo com a Docker, essas imagens foram publicadas em repositórios das organizações convertidas ou dos proprietários indicados; na maioria dos casos, as contas envolvidas pertenciam à mesma pessoa ou equipe. A empresa informou que não encontrou evidências de exploração maliciosa.
Usuários identificados como potencialmente afetados foram notificados, e os tokens associados ao problema foram desativados. Ainda assim, quem utiliza o Docker Hub pode revisar as credenciais e os repositórios para confirmar que não há acessos ou imagens desconhecidos.
Uma verificação útil é conferir os tokens de acesso pessoal ativos e remover credenciais que não sejam mais necessárias. Se um token deixou de ser confiável, o procedimento mais seguro é revogá-lo e criar outro apenas para os sistemas que realmente precisam dele. O novo segredo deve receber o menor conjunto de permissões possível e ser armazenado em um gerenciador de segredos, não em arquivos públicos ou repositórios de código.
Também vale revisar o histórico de publicação dos repositórios: versões recentes, responsáveis pelas alterações e tags inesperadas. Em ambientes de produção, equipes podem comparar as imagens utilizadas com as versões aprovadas e reconstruir aquelas cuja origem não esteja clara. A adoção de processos de revisão antes da publicação reduz o risco de que uma credencial comprometida se transforme em uma alteração distribuída aos usuários.
O caso reforça a importância de tratar tokens como senhas: eles devem ser exclusivos, ter permissões limitadas e ser substituídos quando houver dúvida sobre sua exposição. Organizações que compartilham responsabilidades no Docker Hub também devem manter registros de quem pode publicar ou apagar imagens e retirar acessos que não sejam mais necessários.
A Docker documentava o comportamento vulnerável desde 2025, segundo as informações divulgadas sobre o incidente. A correção encerrou a possibilidade de reutilizar os tokens transferidos com a identidade de outra conta, mas a revisão das credenciais e do conteúdo publicado continua sendo uma medida prudente para equipes que dependem do registro.