Uma falha crítica no Red Hat Quay permite que um atacante com acesso a um registro do Quay leia e sobrescreva imagens de contêiner privadas em todos os repositórios.
O Quay habilita o acesso anônimo por padrão e, enquanto essa opção estiver ativada, o atacante não precisa de nenhuma conta. Quando ela está desativada, qualquer pessoa com uma conta válida ainda pode explorar a falha, disse a Red Hat ontem. A empresa lançou versões corrigidas para oito ramificações do Quay 3.
A falha está catalogada como CVE-2026-123710 (sigla de Vulnerabilidades e Exposições Comuns, sistema de identificação de falhas de segurança), com pontuação CVSS de 9,8 (sigla de Common Vulnerability Scoring System, sistema de pontuação de gravidade de vulnerabilidades).
O Quay usa chaves em que confia para assinar os tokens de acesso que permitem enviar e baixar imagens. A falha permite que um atacante adicione sua própria chave à lista de chaves confiáveis do Quay, sem data de expiração. Em seguida, o Quay passa a aceitar tokens assinados com essa chave para qualquer repositório.
Com esses tokens, o atacante pode obter imagens privadas e quaisquer segredos ou credenciais armazenados nelas. Ele também pode enviar ou sobrescrever imagens, e a alteração se propaga para todos os sistemas que depois baixarem essas imagens.
A chave plantada sobrevive a reinicializações até que alguém a remova. Ela também pode ser usada para apagar as chaves que as instâncias do Quay em execução utilizam, fazendo com que envios e downloads normais passem a falhar com erros de autenticação.
O servidor de chaves do Quay verifica se uma solicitação para substituir uma chave traz um token assinado por uma chave confiável, com o público-alvo e o emissor esperados. Não verifica, porém, se o token foi emitido para rotação de chaves. Um token anônimo do endpoint /v2/auth passa nessa verificação: o Quay o assina com uma chave confiável, e quem faz a chamada escolhe o público-alvo.
Uma segunda falha crítica, CVE-2026-110697 (pontuação CVSS: 9,9), foi divulgada ao mesmo tempo. Ela permite que um usuário do Quay que possa criar um namespace roube tokens de contas de robô de outros locatários e os use para ler, enviar ou sobrescrever imagens desses locatários.
A falha está no código que lista as contas de robô. Ele monta um padrão LIKE da linguagem SQL (Linguagem de Consulta Estruturada) a partir do nome do namespace, sem escapar caracteres curinga. No SQL LIKE, o sublinhado corresponde a qualquer caractere único.
Assim, um namespace com sublinhado no lugar certo pode corresponder ao namespace de outro locatário e retornar suas contas de robô, com os tokens descriptografados. O atacante não precisa de privilégios elevados, e a vítima não precisa fazer nada.
Apagar o namespace do atacante também apaga as contas de robô correspondentes, o que pode interromper sistemas que dependem delas. Quando o Quay é o registro integrado do OpenShift, credenciais de robô roubadas podem ser usadas para injetar imagens maliciosas em pipelines de CI/CD (integração e entrega contínuas), afirma a empresa.
Dave O'Connor, da Red Hat, encontrou as duas falhas. A lógica por trás da CVE-2026-123710 está no Quay desde a primeira confirmação de código (commit) pública, segundo o relatório de bug dessa falha.
A Red Hat lista todas as versões do Quay 3 e do Quay 5 como afetadas pelas duas falhas. Para a CVE-2026-123710, a orientação da empresa cita como afetadas as instalações independentes, o Quay implantado pelo Quay Operator no OpenShift e o mirror registry para Red Hat OpenShift.
Qualquer instância do Quay que clientes não confiáveis possam acessar está exposta, inclusive registros internos, afirma a empresa.
Ao ser consultada hoje, a página CVE da CVE-2026-123710 ainda mostrava todos os pacotes do Quay como afetados e sem correção, embora cada aviso liste a falha.
A empresa recomenda estas medidas:
- No proxy ou balanceador de carga, bloquear o endpoint /keys para todos, exceto componentes internos confiáveis.
- Pesquisar nos logs de auditoria os eventos service_key_rotate e service_key_delete em que expiration_date seja nulo.
- Remover as chaves de serviço aprovadas que você não reconhecer.
- Instalar a versão corrigida. Até que ela esteja em execução, um atacante pode adicionar uma nova chave da mesma forma, então apagar uma chave não resolve de forma duradoura.
«Desativar o acesso anônimo não protege você», diz a empresa no artigo de remediação de chaves. Uma chave plantada também continua funcionando após redefinições de senha e alterações no token da conta de robô.
Para a CVE-2026-110697, a página CVE da empresa lista as mesmas oito versões como corrigidas, afirma que atualizar é a única correção completa e diz que o Quay.io já está corrigido. No entanto, nenhum dos oito avisos lista a CVE-2026-110697.
Até que uma atualização esteja instalada, a empresa sugere limitar quem pode criar organizações ou namespaces que contenham sublinhado, renovar os tokens de conta de robô de qualquer namespace que corresponda a um namespace com sublinhado e monitorar downloads ou envios que não se encaixem no uso normal das contas de robô. Essas medidas reduzem a exposição, mas a falha permanece.
A correção upstream acrescenta a verificação de rotação que faltava, exige que chaves adicionadas pelo servidor de chaves tenham data de expiração e impede que quem faz a chamada escolha o público-alvo do token. A mesma alteração também corrige a busca de contas de robô.
