PENTESTY · ANÁLISE EDITORIAL · · 4 min de leitura
GhostPat no Docker Hub: como revisar tokens e a confiança nas imagens
Uma correção no Docker Hub reforça a importância de verificar quem pode publicar imagens. Um roteiro original para revisar credenciais, mudanças de titularidade e evidências de integridade na entrega de software.
Por Pentesty
O que a Docker confirmou
Em comunicado de 12 de outubro de 2026, a Docker informou que corrigiu a CVE-2026-105445 em 30 de setembro. A conversão de contas em organizações podia transferir tokens pessoais sem alterar seus segredos, permitindo operações no registro sob outra identidade. A empresa não encontrou evidências de exploração e descreveu limitações na investigação. A falha não permitia assumir integralmente a conta.
Por que a confiança precisa acompanhar cada publicação
Para uma empresa que entrega software em contêineres, a pergunta útil é quem pode transformar uma alteração em um artefato distribuído. Um repositório conhecido tem valor operacional, mas seu nome não substitui a verificação das permissões usadas para publicar nele.
Considere uma equipe que mantém ambientes separados de desenvolvimento e produção. Se uma automação de teste também consegue substituir a imagem consumida em produção, a separação visual entre ambientes deixa de representar a autoridade real. Nossa análise é que esse caminho precisa ser identificado antes de decidir quais controles adicionar.
Isso exige conversar com desenvolvimento, plataforma e segurança. O responsável por uma credencial, o dono do repositório e o aprovador de uma implantação podem ser pessoas diferentes. Um inventário útil registra essas relações, a finalidade do acesso e as condições de encerramento.
Um roteiro de testes com resultados observáveis
Execute os cenários somente em contas e repositórios de teste autorizados. Defina responsáveis, janela, dados fictícios e critérios de interrupção. A proposta abaixo avalia seu desenho de permissões; não exige reproduzir a vulnerabilidade já corrigida.
- Mapear a autoridade de publicação. Separe leitura, envio e exclusão de imagens por automação. Evidência: Uma matriz de credenciais e repositórios, com justificativa e responsável por cada permissão.
- Testar fronteiras entre projetos. Use uma credencial de laboratório para tentar uma operação que deveria ser negada em outro namespace controlado. Evidência: Pedido, identidade usada, resposta observada e horário, sem registrar o segredo.
- Validar o fim do acesso. Revogue uma credencial fictícia e repita a operação pela mesma automação. Evidência: Falha de autenticação após a revogação e comprovação de que a credencial substituta funciona apenas no escopo previsto.
- Relacionar artefato e aprovação. Acompanhe uma imagem de laboratório desde a revisão do código até sua implantação. Evidência: Referência do commit, execução da construção, identificador imutável da imagem e registro de aprovação.
Como avaliar uma mudança de titularidade
Mudanças de equipe, desligamentos e reorganizações merecem um procedimento próprio. Liste quais credenciais deveriam continuar funcionando, quais precisam ser substituídas e quem pode autorizar a continuidade. Depois compare a política declarada com o comportamento observado.
A documentação da Docker apresenta tokens de organização como alternativa para automações corporativas e orienta restringir seus recursos. A escolha concreta depende das funções e condições do serviço contratado. Registre a decisão e confirme se ela elimina dependências desnecessárias de contas pessoais.
Nossa recomendação é testar também a recuperação. Uma publicação bloqueada corretamente pode interromper uma entrega legítima se ninguém souber substituir a credencial. Segurança e continuidade precisam aparecer na mesma evidência.
Conecte o achado ao risco do seu ambiente
Uma lista de permissões excessivas ganha utilidade quando mostra o caminho até um serviço importante. Relacione o repositório ao sistema que consome suas imagens, aos dados processados e à pessoa que pode interromper uma distribuição inesperada.
Os artigos relacionados aprofundam a gestão de credenciais, os caminhos entre nuvem e aplicações e a leitura crítica de relatórios. Use essas referências para definir o que precisa ser demonstrado no seu próximo teste.
Perguntas frequentes
Preciso instalar um patch local para esta falha?
Consulte o comunicado do serviço e as notificações da sua conta. Evite aplicar instruções de correção de outro produto apenas porque ele também usa o nome Docker.
Uma imagem de um namespace conhecido é suficiente?
É um ponto de identificação. A decisão de uso também deve considerar como a imagem foi construída, aprovada e publicada.
Devo remover todas as credenciais pessoais?
Revise finalidade, titularidade e escopo antes de uma mudança. Planeje a substituição para evitar interrupções de automações legítimas.
Como comprovar a correção?
Repita o cenário autorizado com credenciais de teste e registre a negativa esperada, a publicação permitida e o responsável pela validação.
Fontes e referências
- Docker: aviso de segurança CVE-2026-105445
- Cyber Security Brazil: referência editorial da notícia
- Docker: tokens de acesso de organização
Análise original da Pentesty, publicada em 15 de outubro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.