Docker corrige falha crítica CVE-2026-105445 que permitia publicar imagens em contas de outros usuários

A Docker corrigiu uma vulnerabilidade crítica no Docker Hub que permitia a um usuário realizar operações em repositórios de outras contas, incluindo publicação, download e exclusão de imagens de contêineres. Identificada como CVE-2026-105445, a falha recebeu pontuação 9,4 no CVSS 4.0 e permaneceu presente na plataforma por pouco mais de dois anos.

A correção foi implementada em 30 de setembro de 2026, enquanto o comunicado oficial de segurança foi publicado em 12 de outubro. Segundo a Docker, uma investigação dos registros da plataforma não encontrou evidências de exploração maliciosa da vulnerabilidade.

O problema estava relacionado ao mecanismo que permite converter contas pessoais do Docker Hub em organizações. Durante esse processo, os tokens de acesso pessoal (Personal Access Tokens, ou PATs) eram transferidos para o usuário designado como proprietário da nova organização, sem invalidar os segredos utilizados anteriormente.

Esses tokens funcionam como credenciais de autenticação para operações no registro de imagens, substituindo o uso direto de senhas. Como os valores dos tokens permaneciam válidos após a transferência, seus criadores continuavam capazes de utilizá-los, agora com a identidade do novo proprietário.

Falha permitia assumir permissões de outros usuários no registro

O Docker Hub não permite transferir diretamente um repositório entre contas. Para manter o mesmo nome de usuário ou namespace, a plataforma oferece a possibilidade de converter uma conta pessoal em organização, indicando outra conta existente como proprietária.

A vulnerabilidade ocorria porque essa conversão modificava a identidade associada aos tokens, mas preservava suas credenciais originais.

Um invasor poderia explorar o comportamento criando um token em uma conta sob seu controle, convertendo essa conta em organização e indicando outra pessoa como proprietária.

Após a conversão, o token poderia ser utilizado no registro do Docker Hub com as permissões da conta escolhida como proprietária.

Segundo a Docker e os pesquisadores responsáveis pela descoberta, o usuário indicado não precisava confirmar a transferência e também não recebia uma notificação, apesar de a interface informar, desde pelo menos agosto de 2024, que um e-mail seria enviado ao novo proprietário.

Dependendo do nível de permissão do token, o invasor poderia baixar, publicar ou excluir imagens em repositórios da vítima e em organizações às quais ela tivesse acesso.

A Docker classificou o problema como crítico principalmente pela possibilidade de publicar imagens utilizando a identidade de um usuário legítimo, criando riscos para a integridade da cadeia de suprimentos de software.

A exploração, entretanto, estava limitada às operações do registro de imagens. A falha não permitia acessar a interface web do Docker Hub, modificar senhas, alterar endereços de e-mail, desabilitar autenticação de dois fatores ou assumir integralmente uma conta.

Vulnerabilidade GhostPat foi descoberta por pesquisadores independentes

A falha, denominada GhostPat, foi identificada por Peter Molnar e Krisztian Hozak, da mptrdev.com.

Os pesquisadores reproduziram o problema duas vezes utilizando contas de teste com autorização dos envolvidos.

Durante os experimentos, conseguiram autenticar-se no registro com a identidade de outra conta, criar e publicar imagens em seu namespace, enviar imagens para uma organização da qual ela participava e acessar repositórios privados.

A Docker informou que disponibilizou a correção menos de quatro horas após receber o relatório dos pesquisadores.

Como a vulnerabilidade estava presente no próprio serviço Docker Hub, a atualização foi aplicada diretamente pela empresa, sem necessidade de instalação de patches pelos usuários.

O problema existia desde 26 de agosto de 2024 e foi corrigido em 30 de setembro de 2026.

Docker analisou aproximadamente 304 mil publicações de imagens

Após a correção, a Docker iniciou uma investigação para determinar se a vulnerabilidade havia sido utilizada indevidamente.

A empresa examinou todas as conversões de contas realizadas durante o período de exposição, comparando registros de autenticação, utilização de tokens e operações no registro.

A análise procurou identificar credenciais utilizadas sob diferentes identidades e verificou aproximadamente 304 mil operações de publicação de imagens realizadas com tokens transferidos.

Segundo a Docker, todas essas publicações ocorreram em repositórios pertencentes às organizações convertidas ou aos proprietários designados.

Na maioria dos casos, as duas contas envolvidas pertenciam à mesma pessoa ou equipe.

Quando não foi possível confirmar essa relação, a empresa examinou as imagens públicas consideradas de maior risco, sem executá-las, e não encontrou indícios de malware ou adulteração.

Apesar dos resultados, a investigação apresenta limitações. Os registros do Docker Hub identificam quando um token é utilizado, mas não necessariamente sua existência caso nunca tenha sido empregado.

Por esse motivo, todos os tokens transferidos durante o período da vulnerabilidade foram considerados potencialmente afetados.

Além disso, o comunicado detalha os resultados das operações de publicação, mas não esclarece as conclusões sobre downloads ou exclusões realizados com esses tokens, incluindo possíveis acessos a repositórios privados.

Usuários afetados foram notificados e tokens desativados

Em 2 de outubro, a Docker enviou notificações aos usuários que receberam tokens transferidos e aos proprietários das organizações envolvidas.

As mensagens incluíam a descrição e a data de criação de cada token identificado.

A empresa não divulgou a quantidade exata de usuários ou credenciais afetadas, limitando-se a informar que o problema envolveu um número restrito de contas.

Segundo a Docker, usuários que não receberam notificações não foram expostos à vulnerabilidade e não precisam realizar ações específicas relacionadas ao incidente.

Em 8 de outubro, a empresa desativou os tokens transferidos identificados, exceto aqueles cuja manutenção havia sido solicitada pelos respectivos proprietários.

Todd Matens, responsável pela ferramenta de análise Docker Compose compose-lint, relatou ter recebido duas notificações, uma relacionada à sua organização e outra à conta pessoal.

Como medida preventiva, ele substituiu dois tokens utilizados em processos de integração contínua (CI) e verificou as assinaturas de suas 42 imagens publicadas, relacionando cada uma ao processo automatizado responsável por sua criação.

Recomendações para verificar credenciais e repositórios

A Docker orienta os usuários a revisar os tokens existentes, revogar credenciais desconhecidas ou desnecessárias e utilizar tokens específicos de organização para automações corporativas.

A verificação pode ser realizada em Account settings → Personal access tokens, onde são apresentadas as datas de criação e última utilização das credenciais.

Os pesquisadores também recomendam observar dois possíveis indicadores de exposição: tokens que o usuário não reconhece e organizações desconhecidas exibidas no seletor de contas.

Para organizações que utilizam os planos Docker Team ou Docker Business, os administradores podem consultar registros de atividades para identificar publicações anteriores, incluindo as tags enviadas e os tokens utilizados.

Esses registros ficam disponíveis no Docker Home por 30 dias, enquanto informações mais antigas podem ser consultadas por meio da API do Docker Hub.

Os tokens de organização exigem assinaturas Team ou Business e podem ser administrados por proprietários ou funções personalizadas autorizadas. Entretanto, não são compatíveis com Docker Desktop ou Image Access Management.

Documentação descrevia comportamento vulnerável desde 2025

Um aspecto identificado na investigação envolve a própria documentação oficial da Docker.

Em 22 de abril de 2025, uma atualização na página de conversão de contas passou a informar que os tokens pessoais associados à conta seriam transferidos ao proprietário da organização.

Essa descrição permaneceu publicada durante aproximadamente 17 dos 25 meses em que a vulnerabilidade esteve presente.

A referência foi removida em 30 de setembro de 2026, poucos minutos após o horário informado pela Docker para a implementação da correção, conforme o histórico público da documentação.

A empresa informou que agora exige o consentimento do usuário antes de designá-lo como proprietário de uma organização e envia notificações sobre a alteração.

Também passou a registrar todas as mudanças de propriedade dos tokens e iniciou uma revisão de outras funcionalidades que permitem modificar a titularidade de credenciais.

A vulnerabilidade apresenta riscos associados a ataques à cadeia de suprimentos de software. Em março e abril, invasores utilizaram credenciais roubadas de publicadores para distribuir imagens maliciosas das ferramentas Trivy e KICS em repositórios legítimos do Docker Hub, em incidentes citados pela empresa como exemplos dos possíveis impactos desse tipo de acesso indevido.

Embora a Docker não tenha encontrado evidências de exploração da GhostPat, o caso demonstra como falhas no gerenciamento de credenciais podem permitir operações não autorizadas em repositórios confiáveis, mesmo sem o comprometimento completo das contas.