Quatro vulnerabilidades foram identificadas no controlador de ingress do Kubernetes, ingress-nginx, permitindo a execu\u00e7\u00e3o de c\u00f3digo em servidores de sistemas em nuvem que utilizam a plataforma Kubernetes, resultando em acesso total privilegiado ao cluster Kubernetes. As quest\u00f5es foram classificadas com um n\u00edvel cr\u00edtico de severidade (9.8 em 10). Os pesquisadores que identificaram os problemas deram \u00e0s vulnerabilidades o codinome IngressNightmare e observaram que as falhas afetam cerca de 43% dos ambientes em nuvem. As vulnerabilidades foram corrigidas nas vers\u00f5es ingress-nginx 1.11.5 e 1.12.1. <\/p>\n
O controlador de ingress atua como um gateway e \u00e9 utilizado no Kubernetes para gerenciar o acesso da rede externa aos servi\u00e7os dentro do cluster. O controlador ingress-nginx \u00e9 o mais popular e aplica servidor<\/a> NGINX para encaminhar solicita\u00e7\u00f5es ao cluster, roteando solicita\u00e7\u00f5es externas e balanceando carga. O projeto Kubernetes oferece controladores de ingress b\u00e1sicos para AWS, GCE e nginx, sendo que este \u00faltimo n\u00e3o est\u00e1 relacionado ao controlador kubernetes-ingress, que \u00e9 mantido pela empresa F5\/NGINX (as vulnerabilidades discutidas n\u00e3o afetam projetos desenvolvidos pelos desenvolvedores do NGINX, e a men\u00e7\u00e3o ao nginx no nome ingress-nginx est\u00e1 apenas relacionada ao uso do nginx como proxy). <\/p>\n As vulnerabilidades permitem que um atacante n\u00e3o autenticado consiga executar seu c\u00f3digo no contexto do controlador ingress-nginx, ao ter a capacidade de enviar uma solicita\u00e7\u00e3o ao manipulador web Admission. Durante a varredura de rede, mais de 6500 clusters Kubernetes vulner\u00e1veis foram detectados, utilizando controladores vulner\u00e1veis p\u00fablicos com o manipulador Admission acess\u00edvel a solicita\u00e7\u00f5es externas. <\/p>\n Na configura\u00e7\u00e3o padr\u00e3o, o c\u00f3digo executado pelo atacante pode acessar as configura\u00e7\u00f5es do objeto Ingress, onde, entre outras coisas, est\u00e3o armazenadas as credenciais para se conectar aos servidores Kubernetes, possibilitando o acesso privilegiado a todo o cluster. Como uma medida de seguran\u00e7a, recomenda-se desativar a fun\u00e7\u00e3o \"Validating Admission Controller\" no ingress-nginx. <\/p>\n O controlador Admission \u00e9 iniciado em um ambiente de pod separado e realiza a verifica\u00e7\u00e3o de objetos ingress recebidos antes de sua implanta\u00e7\u00e3o. Por padr\u00e3o, o manipulador web Admission aceita solicita\u00e7\u00f5es sem autentica\u00e7\u00e3o da rede p\u00fablica. Durante a verifica\u00e7\u00e3o, o controlador Admission cria uma configura\u00e7\u00e3o para o servidor http nginx com base no conte\u00fado do objeto ingress recebido e verifica sua validade. <\/p>\n As vulnerabilidades identificadas permitem a substitui\u00e7\u00e3o de suas pr\u00f3prias configura\u00e7\u00f5es no nginx atrav\u00e9s do envio de um objeto ingress formatado especificamente diretamente para o controlador Admission. Pesquisadores descobriram que algumas propriedades das requisi\u00e7\u00f5es de verifica\u00e7\u00e3o, definidas no campo \".request.object.annotations\", s\u00e3o diretamente inclu\u00eddas na configura\u00e7\u00e3o do nginx. A configura\u00e7\u00e3o gerada n\u00e3o \u00e9 aplicada, mas apenas testada executando o arquivo execut\u00e1vel \"nginx\" com a op\u00e7\u00e3o \"-t\". <\/p>\n Em particular, a substitui\u00e7\u00e3o de dados externos na configura\u00e7\u00e3o \u00e9 realizada para os par\u00e2metros \"mirror-target\", \"mirror-host\" (CVE-2025-1098), \"auth-tls-match-cn\" (CVE-2025-1097) e \"auth-url\" (CVE-2025-24514). Por exemplo, na linha de configura\u00e7\u00e3o \"set $target {{ $externalAuth.URL }};\" em vez de \"{{ $externalAuth.URL }}\" \u00e9 inserido o URL especificado no par\u00e2metro \"auth-url\". Neste caso, a validade do URL n\u00e3o \u00e9 verificada. Assim, o atacante pode transmitir como URL um valor como \"http:\/\/example.com\/#;\nconfigura\u00e7\u00f5es\" e inserir suas pr\u00f3prias configura\u00e7\u00f5es no arquivo de configura\u00e7\u00e3o. <\/p>\n Para executar c\u00f3digo arbitr\u00e1rio durante a verifica\u00e7\u00e3o da configura\u00e7\u00e3o com o comando \"nginx -t\", os pesquisadores aproveitaram o fato de que al\u00e9m de verificar a sintaxe, o nginx carrega bibliotecas com m\u00f3dulos e abre arquivos mencionados na configura\u00e7\u00e3o para avaliar sua disponibilidade. Entre outros, ao processar a diretiva ssl_engine, ocorre o carregamento da biblioteca compartilhada especificada na diretiva. SSL<\/a>-o mecanismo. <\/p>\n Para carregar sua biblioteca no servidor Kubernetes, os pesquisadores se aproveitaram do (CVE-2025-1974) do fato de que, ao processar grandes solicita\u00e7\u00f5es, o nginx salva o corpo da solicita\u00e7\u00e3o em um arquivo tempor\u00e1rio, que \u00e9 imediatamente deletado, mas no sistema de arquivos \u00ab\/proc\u00bb permanece um descritor de arquivo aberto para esse arquivo. Assim, \u00e9 poss\u00edvel enviar solicita\u00e7\u00f5es simultaneamente para salvar o arquivo tempor\u00e1rio e iniciar a verifica\u00e7\u00e3o da configura\u00e7\u00e3o, onde o caminho do descritor no sistema de arquivos \u00ab\/proc\u00bb \u00e9 especificado na diretiva \u00abssl_engine\u00bb. <\/p>\n Para que o descritor de arquivo permane\u00e7a acess\u00edvel por um longo per\u00edodo, o valor \u00abContent-Length\u00bb na solicita\u00e7\u00e3o pode ser especificado como deliberadamente maior do que os dados realmente enviados (o servidor aguardar\u00e1 a recep\u00e7\u00e3o dos dados restantes). Uma complexidade adicional \u00e9 a necessidade de adivinhar o PID do processo e o n\u00famero do descritor de arquivo associado \u00e0 biblioteca compartilhada carregada, mas como geralmente \u00e9 usado um n\u00famero m\u00ednimo de processos em um cont\u00eainer, os valores necess\u00e1rios s\u00e3o adivinhados por tentativa e erro em algumas tentativas. Em caso de sucesso e carregamento da biblioteca compartilhada injetada, o atacante pode obter acesso aos par\u00e2metros armazenados dentro do ambiente pod, suficientes para controlar todo o cluster.