Il 24 marzo i manutentori di ingress-nginx, il controller che in moltissimi cluster Kubernetes instrada il traffico esterno verso i servizi, hanno pubblicato le correzioni per cinque vulnerabilità scoperte dai ricercatori di Wiz. L’insieme è stato battezzato IngressNightmare. Secondo il progetto Kubernetes, ingress-nginx è usato da oltre il 40% degli amministratori di cluster.
La falla più grave, la CVE-2025-1974, ha punteggio 9,8 e riguarda il webhook di ammissione, il componente che valida le nuove risorse Ingress prima che vengano applicate. Per farlo, il controller generava una configurazione NGINX e la sottoponeva a un test. Le altre quattro falle permettono di infilare direttive arbitrarie in quella configurazione attraverso le annotazioni delle risorse Ingress. In altre parole, il test di validazione eseguiva il codice che avrebbe dovuto controllare.
Il risultato è che chiunque raggiunga il webhook dalla rete dei pod, anche senza credenziali, può far eseguire codice al controller. E siccome il controller, per impostazione predefinita, può leggere tutti i Secret del cluster, l’attaccante può arrivare a prenderne il controllo completo. I ricercatori stimano che oltre 6.000 installazioni abbiano il webhook esposto direttamente su Internet. Per ora non risultano attacchi in corso.
La rete dei pod non è un posto sicuro
Il dettaglio che conta è «dalla rete dei pod». In molti cluster qualunque container può parlare con qualunque altro, perché nessuno ha mai scritto una regola di rete. Basta quindi un’applicazione vulnerabile qualsiasi, magari un vecchio servizio dimenticato, per arrivare al webhook e da lì a tutti i segreti.
Sono vulnerabili le versioni precedenti alla 1.11.5 e la 1.12.0; quelle corrette sono la 1.12.1 e la 1.11.5. Il progetto NGINX Ingress Controller di F5, dal nome simile ma con codice diverso, non è coinvolto.
Verifica se lo usi con kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx e aggiorna subito. Se non puoi, disattiva temporaneamente il webhook di ammissione, per esempio con l’opzione Helm controller.admissionWebhooks.enabled=false, e riattivalo dopo l’aggiornamento.
Poi scrivi la regola di rete che mancava: il webhook deve essere raggiungibile solo dal server API di Kubernetes, e mai dall’esterno del cluster. Già che ci sei, chiediti quali altri servizi interni sono aperti a tutti i pod senza motivo.
