Duas vulnerabilidades críticas no Red Hat Quay, plataforma utilizada para armazenar, gerenciar e distribuir imagens de contêineres, colocam em risco a segurança de ambientes corporativos que utilizam Kubernetes e Red Hat OpenShift. Identificadas como CVE-2026-123710 e CVE-2026-110697, as falhas receberam pontuações CVSS 3.1 de 9,8 e 9,9, respectivamente, e podem permitir que invasores acessem imagens privadas, roubem credenciais e substituam componentes utilizados por aplicações em produção.
O cenário preocupa especialmente equipes de DevOps e segurança porque as vulnerabilidades atingem mecanismos fundamentais do registro de contêineres: a validação de chaves utilizadas para assinar tokens de acesso e o isolamento de contas de robô entre diferentes organizações. Na prática, uma exploração bem-sucedida pode comprometer a confidencialidade e a integridade de imagens distribuídas por pipelines de CI/CD.
As duas falhas foram divulgadas em 11 de novembro de 2026 e atribuídas ao pesquisador Dave O’Connor, da Red Hat. Embora tenham mecanismos diferentes, ambas podem abrir caminho para ataques à cadeia de suprimentos de software. A situação exige atenção imediata, principalmente porque desabilitar o acesso anônimo ao registro, isoladamente, não representa uma correção suficiente para a primeira vulnerabilidade.
CVE-2026-123710: falha crítica na validação de chaves do Red Hat Quay
A CVE-2026-123710 compromete o mecanismo de gerenciamento de chaves de serviço do Red Hat Quay. O problema permite que um invasor sem autenticação adequada instale uma chave de assinatura própria, fazendo com que o registro passe a aceitar tokens falsificados como se fossem legítimos.
Para entender o impacto, é importante considerar como funciona a autenticação da plataforma. O Quay utiliza JSON Web Tokens (JWT) para controlar o acesso aos repositórios. Esses tokens são assinados por chaves confiáveis, permitindo que os serviços verifiquem sua autenticidade antes de autorizar operações sobre imagens.
O problema está na maneira como o servidor responsável pela rotação dessas chaves valida as solicitações recebidas.
Como funciona a exploração da CVE-2026-123710
O mecanismo de rotação deveria aceitar exclusivamente credenciais específicas, emitidas para autorizar operações de gerenciamento de chaves. Entretanto, a implementação vulnerável verifica se o JWT foi assinado por uma chave aprovada e apresenta o emissor e a audiência esperados, mas não confirma se o token foi realmente emitido para uma operação de rotação.
Isso cria uma oportunidade de exploração.
Um invasor pode solicitar um token de registro anônimo por meio do endpoint /v2/auth, utilizando uma audiência sob seu próprio controle. Em seguida, apresenta esse token ao endpoint responsável pela rotação de chaves.
Como a validação não verifica corretamente a finalidade do token, a solicitação pode ser aceita. O atacante consegue, assim, adicionar uma chave própria à lista de chaves confiáveis do registro.
O problema fica ainda mais grave porque a chave maliciosa pode ser instalada sem uma data de expiração.
A partir desse momento, tokens assinados pelo invasor podem ser aceitos pelo Red Hat Quay para diferentes repositórios, permitindo operações que deveriam estar restritas a usuários e serviços autorizados.
Quais são os riscos para imagens privadas?
As consequências vão além do acesso indevido a arquivos. Com uma chave de assinatura controlada pelo invasor, podem ocorrer:
- Exposição de informações confidenciais: acesso a imagens privadas que podem conter código proprietário, configurações e outros dados sensíveis.
- Manipulação de imagens: substituição de tags e publicação de versões adulteradas de contêineres.
- Comprometimento da cadeia de suprimentos: distribuição de imagens maliciosas para aplicações que confiam no registro.
- Persistência do acesso: chaves sem expiração podem continuar válidas mesmo após reinicializações do serviço.
- Negação de serviço: a exclusão de chaves legítimas pode interromper operações que dependem da validação dos tokens.
Um detalhe importante é que remover uma chave desconhecida não resolve definitivamente o problema enquanto a instância continuar vulnerável. O atacante pode repetir a operação e instalar outra chave maliciosa.
CVE-2026-110697: Red Hat Quay expõe contas de robô entre organizações
CVSS 9,9 · Crítica
A segunda vulnerabilidade, CVE-2026-110697, atinge o isolamento entre organizações em instalações multi-tenant do Red Hat Quay.
Nesse modelo de implantação, diferentes equipes, departamentos ou clientes compartilham a mesma infraestrutura, mas devem permanecer isolados uns dos outros. Cada organização possui seus próprios repositórios e contas de robô, utilizadas por sistemas automatizados para autenticar operações de leitura e publicação de imagens.
A falha permite contornar parte desse isolamento e recuperar credenciais pertencentes a outros locatários.
O problema com o caractere sublinhado no SQL LIKE
A causa técnica está na maneira como o Quay constrói consultas SQL para listar contas de robô.
A implementação utiliza o operador LIKE com nomes de namespaces fornecidos pelo usuário, mas não escapa corretamente os caracteres especiais utilizados como curingas.
No SQL, o caractere sublinhado (_) representa qualquer caractere individual. Portanto, uma consulta que deveria corresponder a um nome específico pode acabar correspondendo também a outros nomes com estruturas semelhantes.
Um exemplo simplificado ajuda a entender:
- Namespace legítimo:
equipea. - Padrão utilizado na consulta:
equipe_a. - O sublinhado pode corresponder ao caractere que ocupa aquela posição, permitindo que a consulta alcance outro namespace.
Dessa maneira, um usuário autenticado com permissão para criar uma organização pode explorar nomes contendo sublinhados para fazer a consulta alcançar contas de robô pertencentes a outros tenants.
O resultado é particularmente perigoso porque a falha permite recuperar tokens de autenticação descriptografados dessas contas.
Como isso compromete pipelines de CI/CD?
As contas de robô são frequentemente utilizadas por ferramentas de automação para buscar imagens, publicar versões e alimentar processos de implantação.
Se um invasor consegue obter esses tokens, pode assumir as permissões associadas às contas comprometidas.
Em ambientes com Red Hat OpenShift, o impacto pode atingir diretamente o registro integrado de contêineres e os processos automatizados de distribuição de software.
Um atacante pode utilizar credenciais roubadas para acessar imagens privadas, publicar versões adulteradas ou substituir componentes que serão consumidos por aplicações corporativas.
Isso transforma uma falha de isolamento entre organizações em um possível comprometimento da cadeia de suprimentos.
Versões afetadas e divergências nos avisos de segurança
As duas vulnerabilidades afetam componentes do Red Hat Quay 3 e Red Hat Quay 5, incluindo pacotes para diferentes versões do Red Hat Enterprise Linux.
O cenário envolve instalações independentes, implantações gerenciadas pelo Quay Operator no OpenShift e ambientes que utilizam o registro de espelhos do Red Hat OpenShift, conforme a composição e a versão dos componentes instalados.
A Red Hat informa que o serviço hospedado Quay.io já recebeu as correções. Além disso, foram disponibilizadas oito versões atualizadas do Quay 3:
| Versão corrigida |
|---|
| Quay 3.9.28 |
| Quay 3.10.28 |
| Quay 3.12.24 |
| Quay 3.14.10 |
| Quay 3.15.9 |
| Quay 3.16.7 |
| Quay 3.17.7 |
| Quay 3.18.3 |
Entretanto, existe uma divergência importante na documentação oficial que merece atenção dos administradores.
O boletim da CVE-2026-110697 apresenta essas oito versões como corrigidas, mas os respectivos avisos de errata publicados para as imagens atualizadas não identificam explicitamente essa CVE entre as falhas corrigidas.
Além disso, a página da CVE-2026-123710 ainda apresenta os componentes do Quay como afetados, sem indicar claramente as versões corrigidas.
Portanto, administradores não devem considerar uma instalação protegida apenas porque identificaram uma dessas versões. É necessário conferir os avisos de segurança, as imagens disponibilizadas e a orientação específica da Red Hat para cada implantação.
Como mitigar e corrigir as vulnerabilidades imediatamente
A recomendação prioritária é atualizar as instâncias afetadas para versões corrigidas e aplicar as medidas emergenciais enquanto a atualização não estiver concluída.
A Red Hat apresenta orientações específicas para reduzir a exposição à CVE-2026-123710 e à CVE-2026-110697.
1. Bloqueie o endpoint /keys para tráfego externo
A primeira medida é restringir o acesso ao endpoint /keys no proxy reverso ou balanceador de carga.
Somente componentes internos confiáveis devem conseguir acessar esse recurso. Solicitações provenientes de redes externas ou clientes não autorizados precisam ser bloqueadas.
Essa medida reduz a possibilidade de exploração da falha de rotação de chaves.
É importante verificar se a restrição também funciona em todos os caminhos de acesso utilizados pela instalação, evitando que outro endereço público continue expondo o endpoint.
2. Audite os registros de gerenciamento de chaves
Examine os registros de auditoria do Quay procurando eventos relacionados a:
service_key_rotateservice_key_delete
Dê atenção especial aos eventos que apresentam expiration_date nulo.
Uma chave aprovada sem data de expiração pode indicar uma instalação indevida. Compare todas as chaves registradas com o inventário legítimo da infraestrutura e remova aquelas que não forem reconhecidas.
Essa investigação também ajuda a identificar possíveis tentativas anteriores de exploração.
3. Restrinja namespaces com sublinhados
Para reduzir o risco da CVE-2026-110697, restrinja temporariamente a criação de organizações e namespaces contendo o caractere _.
A medida dificulta a exploração do comportamento inadequado do operador SQL LIKE.
Também é necessário identificar namespaces que possam entrar em conflito com padrões de nomes utilizados por outras organizações.
4. Rotacione os tokens das contas de robô
Revise as contas de robô e identifique possíveis credenciais expostas.
Rotacione os tokens das contas pertencentes a namespaces que possam ter sido afetados e atualize os segredos correspondentes nas ferramentas de CI/CD.
Verifique também os registros de leitura e publicação de imagens para identificar operações inesperadas.
Caso existam sinais de comprometimento, investigue as imagens publicadas durante o período de exposição antes de permitir que sejam utilizadas em produção.
5. Instale as versões corrigidas
As medidas anteriores são paliativas. A proteção definitiva depende da aplicação das atualizações que corrigem os mecanismos vulneráveis.
As versões corrigidas precisam garantir, entre outros aspectos, que a rotação de chaves valide corretamente a finalidade do token, que as chaves respeitem as regras de expiração e que as consultas de contas de robô tratem adequadamente os caracteres especiais.
Em ambientes OpenShift, a atualização também deve considerar a versão do Quay Operator e a compatibilidade das imagens utilizadas.
Não trate o bloqueio do endpoint ou a rotação de credenciais como substitutos da atualização de segurança.
Conclusão: registros de contêineres precisam de proteção prioritária
As vulnerabilidades CVE-2026-123710 e CVE-2026-110697 demonstram como falhas aparentemente específicas em mecanismos de autenticação e isolamento podem comprometer toda uma infraestrutura de distribuição de software.
O Red Hat Quay ocupa uma posição estratégica em ambientes modernos, pois centraliza imagens utilizadas por aplicações, clusters Kubernetes e plataformas OpenShift. Quando um invasor consegue controlar chaves de assinatura ou roubar credenciais de contas de robô, o problema deixa de afetar apenas o registro e pode alcançar os sistemas que consomem seus contêineres.
Com pontuações CVSS de 9,8 e 9,9, as duas vulnerabilidades justificam uma resposta emergencial das equipes responsáveis pela infraestrutura.
Administradores devem revisar imediatamente a exposição dos endpoints, auditar as chaves de serviço, investigar possíveis vazamentos de tokens e aplicar as atualizações disponíveis conforme a orientação da Red Hat.
