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 sua versão instalada, consulte Como verificar o método de instalação e a versão.

Etapa 3: Confirme se o admission webhook está habilitado

Clusters com o admission webhook desabilitado 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á desabilitado.
```
  kubectl get validatingwebhookconfigurations ingress-nginx-admission
```
Instalação via Marketplace: Visualize as informações básicas do aplicativo relacionado 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 desabilitado	Risco reduzido (atualização ainda recomendada)
Instalado, versão afetada, admission webhook habilitado	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). Os passos 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. Em seguida, 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 é a 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 dos 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 nuvem 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 subsequente 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 abusar da anotação `auth-url` da comunidade NGINX Ingress para inserir configurações maliciosas.	Potencial para execução de código arbitrário no contexto do NGINX Ingress controller e extração de Secrets do cluster.	#131006
CVE-2025-24513	Média	4,8	O NGINX Ingress controller não valida ou filtra adequadamente os dados de entrada enviados por usuários com permissão de escrita em recursos Ingress. Atacantes podem criar requisições maliciosas para 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 limitado de instâncias de Secrets no cluster.	#131005

Mitigação temporária

Caso não seja possível atualizar imediatamente, desabilite 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 breve possível.

Para clusters com NGINX Ingress controller instalado pela página de Add-ons

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

Para clusters com NGINX Ingress controller instalado pelo Marketplace

Exclua manualmente o admission webhook relacionado para reduzir o risco:

kubectl delete validatingwebhookconfigurations ingress-nginx-admission

Importante

Desabilitar 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: Atualize para a 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-ons

Caso ainda não tenha feito, desabilite o admission webhook conforme descrito em Mitigação temporária para reduzir riscos durante o preparo da atualização.
Atualize o componente NGINX Ingress controller para a v1.11.5 ou superior. Consulte as Notas de release do NGINX Ingress controller para detalhes sobre as versões e siga as instruções em Atualize o NGINX Ingress controller para realizar a atualização.
Após concluir a atualização, reabilite o admission webhook.

Importante

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

Marketplace

Se ainda não o fez, exclua manualmente o admission webhook conforme descrito em Mitigação temporária para mitigar riscos enquanto prepara a atualização.
Verifique as notas de release do componente na página do Marketplace ou na página Helm no console. Em seguida, atualize o ack-ingress-nginx na página do Marketplace para a v1.11.5 ou superior durante horários de pico reduzido.
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, reabilite-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: Desabilitei o admission webhook. Ainda estou em risco?

Desabilitar 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 reabilitar 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 prevenir interrupções de serviço. Sempre o reabilite após atualizar para uma versão corrigida.

P: Qual a diferença entre os métodos de instalação por 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 desabilitam 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.