Como corrigir as vulnerabilidades CVE-2025-1097, CVE-2025-1098, CVE-2025-1974, CVE-2025-24513 e CVE-2025-24514 - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Meu ambiente é afetado?

Use a árvore de decisão a seguir para verificar se o seu cluster está em risco.

Etapa 1: Verifique se o NGINX Ingress controller está instalado

kubectl get pods -n kube-system --selector app=ingress-nginx

Se nenhum pod for retornado, seu cluster não tem o NGINX Ingress controller instalado e não é afetado. Nenhuma ação adicional é necessária.
Se houver retorno de pods, prossiga para a Etapa 2.

Etapa 2: Identifique a versão em execução

Versões afetadas do NGINX Ingress controller:

Todas as versões anteriores à v1.11.5
v1.12.0

Clusters que executam a v1.11.5, v1.12.1 ou qualquer versão posterior já utilizam uma release corrigida. Nenhuma ação adicional é necessária.

Para identificar a versão instalada, consulte Como verificar o método de instalação e a versão.

Etapa 3: Confirme se o admission webhook está ativado

Clusters com o admission webhook desativado não são afetados pela vulnerabilidade mais crítica (CVE-2025-1974). No entanto, as vulnerabilidades de injeção via anotações (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-24513) ainda se aplicam caso algum usuário tenha permissões de escrita em recursos Ingress. A atualização continua sendo recomendada.

Instalação via Add-ons: Execute o comando abaixo. Se o recurso não for encontrado, o admission webhook está desativado.
```
  kubectl get validatingwebhookconfigurations ingress-nginx-admission
```
Instalação via Marketplace: Visualize as informações básicas do aplicativo correspondente e verifique a existência de algum recurso do tipo ValidatingWebhookConfiguration.

Resumo

Condição	Nível de risco
NGINX Ingress controller não instalado	Não afetado
Instalado, versão >= v1.11.5 (1.11.x) ou >= v1.12.1 (1.12.x)	Não afetado (já corrigido)
Instalado, versão afetada, admission webhook desativado	Risco reduzido (ainda assim, atualize)
Instalado, versão afetada, admission webhook ativado	Afetado — tome providências imediatamente

Como verificar o método de instalação e a versão

O NGINX Ingress controller pode ser instalado em clusters ACK por dois caminhos: página de Add-ons ou Marketplace (Helm chart). As etapas de correção variam conforme o método utilizado.

Instalação pela página de Add-ons

Método 1: Verificação na página de Add-ons

Faça login no ACK console. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, localize o cluster desejado e clique em seu nome. No painel de navegação à esquerda, clique em Add-ons.
Na página Add-ons, pesquise e localize o Nginx Ingress Controller. Verifique no cartão do componente se ele está instalado e qual sua versão atual.

Método 2: Consulta via kubectl

kubectl get pods -n kube-system --selector app=ingress-nginx

Instalação pelo Marketplace (Helm chart)

Faça login no ACK console. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, localize o cluster desejado e clique em seu nome. No painel de navegação à esquerda, escolha Applications > Helm.
Na lista do Helm, verifique se ack-ingress-nginx ou ack-ingress-nginx-v1 aparece na coluna Chart Name. A coluna Application Version indica a versão atual do componente NGINX Ingress controller.

Detalhes das vulnerabilidades

A comunidade Kubernetes divulgou cinco vulnerabilidades de segurança no NGINX Ingress controller. Quatro delas permitem que atacantes injetem configurações maliciosas por meio de anotações Ingress manipuladas. A mais crítica, CVE-2025-1974, possibilita a execução de código sem autenticação por qualquer entidade com acesso à rede de pods, contornando completamente o admission webhook.

Na prática, qualquer workload executado na rede de pods do seu cluster — ou qualquer entidade com acesso de rede ao endpoint do admission controller — pode explorar essas falhas para executar código arbitrário dentro do NGINX Ingress controller e obter todos os Secrets do cluster. Em muitos cenários comuns, a rede de pods é acessível a todos os workloads da sua VPC na cloud, ou até mesmo a qualquer pessoa conectada à rede corporativa. Isso significa que Secrets como certificados TLS, credenciais de API e outros dados sensíveis armazenados no Kubernetes podem ficar expostos.

ID da CVE	Gravidade	Pontuação CVSS v3.1	Descrição	Risco	Referência
CVE-2025-1097	Alta	8,8	Atacantes com permissão de escrita em recursos Ingress podem explorar a anotação `auth-tls-match-cn`, fornecida pela comunidade NGINX Ingress, para injetar configurações maliciosas.	Possibilidade de execução de código arbitrário no contexto do NGINX Ingress controller e obtenção de Secrets em todo o cluster.	#131007
CVE-2025-1098	Alta	8,8	Usuários com permissão de escrita em recursos Ingress podem usar as anotações `mirror-target` e `mirror-host`, da comunidade NGINX Ingress, para injetar configurações maliciosas.	Execução potencial de código arbitrário no contexto do NGINX Ingress controller, permitindo acesso posterior a Secrets do cluster.	#131008
CVE-2025-1974	Crítica	9,8	Atacantes com acesso à rede de pods conseguem contornar o admission webhook para injetar configurações.	Risco de execução de código arbitrário no contexto do NGINX Ingress controller e comprometimento de Secrets em todo o cluster.	#131009
CVE-2025-24514	Alta	8,8	Indivíduos com permissão de escrita em recursos Ingress podem explorar a anotação `auth-url`, fornecida pela comunidade NGINX Ingress, para injetar configurações maliciosas.	Potencial para execução de código arbitrário no contexto do NGINX Ingress controller e acesso subsequente a Secrets do cluster.	#131006
CVE-2025-24513	Média	4,8	O NGINX Ingress controller não valida nem filtra adequadamente os dados de entrada enviados por usuários com permissão de escrita em recursos Ingress. Atacantes podem explorar essa falha para criar requisições maliciosas e injetar dados não autorizados no caminho de geração de arquivos de configuração.	Vulnerabilidades de travessia de diretórios dentro do container podem ser acionadas. Essa falha pode causar negação de serviço (DoS) ou, combinada com outras vulnerabilidades, levar ao vazamento de instâncias limitadas de Secrets no cluster.	#131005

Mitigação temporária

Caso não seja possível atualizar imediatamente, desative o admission webhook para bloquear o vetor de ataque mais crítico (CVE-2025-1974). Trata-se de uma medida temporária — você ainda deve atualizar para uma versão corrigida o mais rápido possível.

Para clusters com NGINX Ingress controller instalado via Add-ons

Na página Add-ons do cluster alvo, localize o componente Nginx Ingress Controller e desative manualmente o recurso de admission webhook. Para mais detalhes, consulte Gerencie o NGINX Ingress controller.

Para clusters com NGINX Ingress controller instalado via Marketplace

Exclua manualmente o admission webhook associado para reduzir o risco:

kubectl delete validatingwebhookconfigurations ingress-nginx-admission

Importante

Desativar ou excluir o admission webhook remove um mecanismo de pré-validação para configurações de Ingress. Embora isso mitigue a vulnerabilidade, configurações inválidas de Ingress deixarão de ser rejeitadas antes de entrarem em vigor. Reative o admission webhook após atualizar para uma versão corrigida.

Correção: Atualização para versão corrigida

A comunidade corrigiu todas as cinco vulnerabilidades nas seguintes versões do NGINX Ingress controller:

v1.11.5
v1.12.1

Atualize para a v1.11.5 ou superior (para a linha de release 1.11.x) ou v1.12.1 ou superior (para a linha de release 1.12.x) durante horários de baixa demanda.

Gerenciamento de Add-on

Caso ainda não tenha feito isso, desative o admission webhook conforme descrito em Mitigação temporária para reduzir riscos enquanto prepara a atualização.
Atualize o componente NGINX Ingress controller para a v1.11.5 ou superior. Consulte NGINX Ingress controller release notes para detalhes sobre versões e siga as instruções em Atualize o NGINX Ingress controller para realizar a atualização.
Após concluir a atualização, reative o admission webhook.

Importante

Ao finalizar a atualização, certifique-se de reativar o recurso de admission webhook. Esse mecanismo atua como pré-validação para configurações de Ingress, melhorando efetivamente a confiabilidade e estabilidade do service. Antes que a criação ou atualização de uma configuração de Ingress entre em vigor, o admission webhook alertará sobre erros, permitindo prevenir problemas operacionais.

Marketplace

Se ainda não o fez, exclua manualmente o admission webhook conforme descrito em Mitigação temporária para mitigar riscos durante o preparo da atualização.
Verifique as notas de release do componente na página Marketplace ou na página Helm do console e atualize o ack-ingress-nginx na página do Marketplace para a v1.11.5 ou superior durante horários de baixa demanda.
Depois de concluir a atualização, verifique se o admission webhook foi recriado como parte da implantação atualizada do Helm chart. Caso contrário, reative-o manualmente.

Referências dos patches

A comunidade tratou cada vulnerabilidade nos seguintes commits (todos parte do PR #13068):

CVE	Commit
CVE-2025-1097	ingress-nginx main@06c992a
CVE-2025-1098	ingress-nginx main@2e9f373
CVE-2025-1974	ingress-nginx main@0ccf4ca
CVE-2025-24513	ingress-nginx main@cbc1590
CVE-2025-24514	ingress-nginx main@ab470eb

Perguntas frequentes

P: Meu cluster não tem o NGINX Ingress controller instalado. Sou afetado?

Não. Clusters sem o NGINX Ingress controller instalado não são impactados por nenhuma dessas vulnerabilidades. Nenhuma ação é necessária.

P: Desativei o admission webhook. Ainda estou em risco?

Desativar o admission webhook bloqueia a vulnerabilidade mais crítica (CVE-2025-1974, CVSS 9,8). Contudo, as vulnerabilidades de injeção baseadas em anotações (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-24513) ainda podem ser exploradas por atacantes que possuam permissões de escrita em recursos Ingress, independentemente da configuração do webhook. A atualização para uma versão corrigida continua sendo necessária.

P: Devo reativar o admission webhook após a atualização?

Sim. O admission webhook funciona como um mecanismo de pré-validação para configurações de Ingress. Ele detecta e rejeita configurações inválidas antes que entrem em vigor, ajudando a evitar interrupções de service. Sempre o reative após atualizar para uma versão corrigida.

P: Qual a diferença entre os métodos de instalação via Add-ons e Marketplace?

O NGINX Ingress controller pode ser instalado no ACK através da página de Add-ons (gerenciado pelo ciclo de vida de add-ons do ACK) ou pelo Marketplace como um Helm chart. Os passos de correção diferem ligeiramente: usuários de Add-ons desativam o webhook pela interface do console, enquanto usuários do Marketplace excluem diretamente o recurso ValidatingWebhookConfiguration. Ambos os caminhos exigem a atualização para a v1.11.5 ou superior.