Uma falha crítica no Red Hat Quay permite que um invasor com acesso a um registro do Quay leia e sobrescreva imagens privadas de contêiner em todos os repositórios.
O acesso anônimo vem habilitado por padrão no Quay. Enquanto essa opção estiver ativa, o invasor não precisa de uma conta. Se ela estiver desativada, qualquer pessoa com uma conta válida ainda poderá explorar a falha, informou a Red Hat ontem. A empresa lançou versões corrigidas para oito linhas do Quay 3.
A vulnerabilidade foi identificada como
CVE-2026-123710
e recebeu pontuação 9,8 no CVSS.
O Quay usa chaves confiáveis para assinar os tokens de acesso que permitem enviar e baixar imagens. A falha permite que um invasor acrescente a própria chave à lista de chaves confiáveis pelo Quay, sem data de expiração. Com isso, o sistema aceita tokens assinados com essa chave para qualquer repositório.
Usando esses tokens, o invasor pode obter imagens privadas e quaisquer segredos ou credenciais armazenados nelas. Também pode enviar ou sobrescrever imagens. A alteração se propaga para todos os sistemas que baixarem essas imagens posteriormente.
A chave inserida permanece ativa após reinicializações, até que alguém a remova. Ela também pode ser usada para excluir as chaves empregadas pelas instâncias do Quay em execução, fazendo com que os envios e downloads habituais comecem a falhar com erros de autenticação.
O servidor de chaves do Quay verifica se uma solicitação para substituir uma chave inclui um token assinado por uma chave confiável, com o público-alvo e o emissor esperados. No entanto, não verifica se o token foi emitido para uma rotação de chaves. Um token anônimo obtido no ponto de acesso /v2/auth é aceito: o Quay o assina com uma chave confiável, e quem faz a solicitação escolhe o público-alvo.
Outra falha crítica,
CVE-2026-110697
, com pontuação 9,9 no CVSS, foi divulgada ao mesmo tempo. Ela permite que um usuário do Quay com permissão para criar um espaço de nomes roube tokens de contas de robô de outros clientes e os use para ler, enviar ou sobrescrever as imagens dessas organizações.
A falha está no código que lista contas de robô. Ele cria um padrão SQL LIKE com base no nome do espaço de nomes, sem escapar caracteres curinga. No SQL LIKE, o caractere de sublinhado corresponde a qualquer caractere individual.
Assim, um espaço de nomes com um sublinhado na posição adequada pode corresponder ao espaço de nomes de outro cliente e revelar as contas de robô associadas, junto com seus tokens descriptografados. O invasor não precisa de privilégios elevados, e a vítima não precisa realizar nenhuma ação.
Excluir o espaço de nomes do invasor também exclui as contas de robô correspondentes, o que pode interromper sistemas que dependem delas. Quando o Quay é o registro integrado ao OpenShift, credenciais de robô roubadas podem ser usadas para inserir imagens maliciosas em fluxos de CI/CD, informou a empresa.
Dave O’Connor, da Red Hat, encontrou as duas falhas. Segundo o registro da
CVE-2026-123710
, a lógica por trás dessa vulnerabilidade está no Quay desde o primeiro envio público de código do projeto.
A Red Hat informa que todas as versões do Quay 3 e do Quay 5 são afetadas pelas duas falhas. Para a
CVE-2026-123710
, a empresa inclui entre as instalações vulneráveis as versões independentes, as implementações do Quay pelo Quay Operator no OpenShift e o registro espelhado do Red Hat OpenShift.
Qualquer instância do Quay acessível a clientes não confiáveis está exposta, incluindo registros internos, segundo a empresa.
Na consulta feita hoje, a entrada da
CVE-2026-123710
ainda indicava que todos os pacotes do Quay eram afetados e não apresentavam correção, embora os avisos de segurança da empresa listassem a vulnerabilidade.
A Red Hat recomenda as seguintes medidas:
- No proxy ou balanceador de carga, bloquear o ponto de acesso /keys para todos, exceto componentes internos confiáveis.
- Procurar nos registros de auditoria eventos service_key_rotate e service_key_delete em que expiration_date seja nulo.
- Remover quaisquer chaves de serviço aprovadas que não sejam reconhecidas.
- Instalar a versão corrigida. Enquanto ela não estiver em execução, um invasor poderá adicionar uma nova chave da mesma forma. Portanto, excluir uma chave não é uma solução duradoura.
“Desativar o acesso anônimo não protege você”, afirma a empresa em seu artigo sobre a correção da falha. Uma chave inserida também continua funcionando após a redefinição de senhas e a alteração do token de robô.
Na página da
CVE-2026-110697
, a empresa aponta as mesmas oito versões como corrigidas, afirma que a atualização é a única solução completa e informa que o Quay.io já foi corrigido. No entanto, nenhum dos oito avisos de segurança menciona a
CVE-2026-110697
.
Até que a atualização seja instalada, a Red Hat recomenda limitar quem pode criar organizações ou espaços de nomes com sublinhados, trocar os tokens de robô de qualquer espaço de nomes que corresponda a outro com sublinhado e monitorar envios e downloads incompatíveis com o uso habitual das contas de robô. Essas medidas reduzem a exposição, mas não eliminam a falha.
A correção no código original acrescenta a verificação de rotação que estava ausente, exige uma data de expiração para as chaves adicionadas pelo servidor de chaves e impede que quem faz a solicitação escolha o público-alvo do token. A mesma alteração também corrige a busca por contas de robô.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...