TL;DR

No Kubernetes, o objeto Ingress define regras HTTP/HTTPS para roteamento de tráfego externo para serviços internos do cluster. Para que essas regras tenham efeito, é necessário um Ingress Controller em execução [1]. O ingress-nginx é um desses controladores, baseado em NGINX, e sua documentação oficial descreve que ele é construído em torno do recurso Ingress, usando ConfigMap para configurações do  controlador [2].

A CVE-2026-24512 descreve uma falha de injeção de configuração no ingress-nginx: o campo  rules.http.paths.path pode ser usado para injetar conteúdo no nginx.conf. O impacto informado  oficialmente inclui execução de código no contexto do controlador e exposição de secrets acessíveis por ele [3][4].

A severidade publicada pela CNA (Kubernetes) é CVSS v3.1 8.8 (High) com vetor AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H [3][4].

A descoberta foi atribuída oficialmente a Maxime Escourbiac e Yassine Bengana (Michelin CERT) [3] [8].

→ Correção da CVE-2026-24512 no Quor.
Aproveite 14 dias grátis da nossa imagem: app.quor.dev

Como a vulnerabilidade acontece

1. Um atacante com permissão para criar/editar Ingress envia um path malicioso em     rules.http.paths.path.

2. O controlador processa esse valor ao renderizar o template NGINX.

3. Sem escaping/quoting adequado, o valor pode “quebrar” a diretiva esperada e injetar configuração adicional.

4. O NGINX recarrega a configuração resultante.

* Em resumo: o problema central é tratamento inseguro de entrada não confiável durante a geração do  nginx.conf [3][6][9].

Fui afetado?

Se você não usa ingress-nginx, esta CVE não se aplica [3].

  1. Verifique se há ingress-nginx no cluster

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

  2. Verifique as imagens/versões em uso

 kubectl get deploy -A -l app.kubernetes.io/name=ingress-nginx \
    -o=jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}
  {range .spec.template.spec.containers[*]}{.name}={.image}{" "}{end}{"\n"}{end}'

  3. Compare com as faixas afetadas

•   ingress-nginx < v1.13.7

•   ingress-nginx < v1.14.3

    (na prática operacional: atualizar para v1.13.7, v1.14.3 ou superior) [3][5].

Exemplo de manifesto com payload válido de teste (não-exploratório)

Este payload é útil para validar sanitização de aspas e barra invertida (mesmo padrão usado nos testes do patch):

 apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: cve-2026-24512-sanitization-test
  spec:
    ingressClassName: nginx
    rules:
    - host: escape.test
      http:
        paths:
        - path: '/"\\'
          pathType: ImplementationSpecific
          backend:
            service:
              name: test
              port:
                number: 80

Com correção aplicada, a renderização esperada mantém o valor dentro de aspas e escapado no nginx.conf, no formato equivalente a:

location "/\"\\\\" {
      ...
  }

Impacto

Inclui a possibilidade de execução de código dentro do pod do ingress-nginx, o que dá ao atacante controle sobre o processo do controlador. Além disso, há risco de vazamento de Secrets acessíveis por esse controlador; em configurações padrão, isso pode abranger Secrets de todo o cluster, ampliando significativamente o alcance do comprometimento. [3]

Correção e por que a falha ocorreu

Patch diff: https://github.com/kubernetes/ingress-nginx/pull/14501/files [9]

O patch corrige a vulnerabilidade escapando e encapsulando o que vinha do Ingress antes de renderizar no nginx.conf, evitando que valores de path ou server_name escapem para  fora da diretiva e injetem configuração.

1. buildLocation agora sempre coloca o path entre aspas e faz escape de \ e " por meio da nova função sanitizeQuotedRegex.

• Antes: o path era inserido cru, inclusive em PathTypeExact (= %s) e no default (%s).

• Agora: PathTypeExact usa = "%s" e o padrão usa "%s", sempre com escape de \ e ".

2. server_name e aliases também passaram a ser quoted/escaped no template NGINX.

• server_name usa | quote e aliases passam por sanitizeQuotedRegex.

De maneira resumida, ao colocar esses valores entre aspas e escapar caracteres especiais isso endereça o risco de injeção de configuração,  impede que entradas maliciosas “fechem” a diretiva e injetem novas instruções no nginx.conf

Recomendação

1. Ação principal: atualizar para v1.13.7, v1.14.3 ou superior [3][5][10].

2. Mitigação temporária: usar validação de admissão para rejeitar Ingress com pathType=ImplementationSpecific até a atualização [3].

3. Monitoramento: tratar valores suspeitos em rules.http.paths.path como indício de tentativa de exploração [3].

Conclusão

A CVE-2026-24512 é crítica para ambientes com ingress-nginx porque combina vetor de injeção em  configuração de proxy com alto impacto potencial (RCE + exposição de secrets). A mitigação por política de admissão reduz risco imediato, mas não substitui atualização para  versões corrigidas.

Referências

[1] https://kubernetes.io/docs/concepts/services-networking/ingress/
[2] https://kubernetes.github.io/ingress-nginx/
[3] https://github.com/kubernetes/kubernetes/issues/136678
[4] https://nvd.nist.gov/vuln/detail/CVE-2026-24512
[5] https://www.runzero.com/blog/k8s-ingress-nginx-controller/
[6] https://owasp.org/www-community/attacks/Code_Injection
[7] https://app.quor.dev/images/76/default/ingress-nginx-controller/details
[8] https://cert.michelin.com/
[9] https://github.com/kubernetes/ingress-nginx/pull/14501
[10] https://kubernetes.github.io/ingress-nginx/deploy/upgrade/