Ingress NGINX, utilizzato ovunque in Kubernetes, ha una vulnerabilità critica di tipo Remote Code Execution

La prima domanda che un neofita di Kubernetes si fa è: tutto bello, ma come faccio a far raggiungere i miei servizi dall’esterno? È una domanda legittima poiché gli elementi Service funzionano solo a livello cluster, quindi internamente sono visibili da chi ne fa parte, ma dall’esterno le cose si complicano.

Una delle soluzioni più utilizzate, che consente di esporre in maniera rapida i servizi HTTP, è un ingress controller. Di fatto si tratta di un reverse proxy che sta in ascolto per connessioni HTTP entranti (quindi porte 80 e 443) sui nodi control-plane ed in base ad un set di regole dirige il traffico internamente al service desiderato.

Tutto chiaro fin qui? Molto bene, perché è proprio in merito ad uno degli ingress controller più usati che la notizia (bomba) che diamo oggi si riferisce: c’è una vulnerabilità di una portata enorme – peso 9.8, ossia CRITICAL – che affligge Ingress NGINX, uno degli ingress controller più usati.

I dettagli di questa problematica, battezzata IngressNightmare, sono raccontati nell’articolo di WIZ che spiega come sia possibile ottenere Unauthenticated Remote Code Execution, quindi l’esecuzione di qualsiasi cosa si voglia, all’interno dei sistemi che montano la versione fallata di Ingress NGINX.

Il funzionamento è riassunto in questo video:

All’interno del quale emerge l’enorme facilità con cui l’attacco può essere perpetrato.

Tecnicamente l’admission controller di Ingress NGINX, ossia l’elemento che analizza le richieste pervenute, costruisce una configurazione NGINX apposita basata sulla richiesta, convalidandola mediante il binario NGINX. Il team di ricerca di WIZ ha trovato la vulnerabilità in questa fase che consente di iniettare una configurazione arbitraria NGINX da remoto, direttamente all’admission controller.

Durante la fase di convalida della configurazione, la configurazione NGINX iniettata fa sì che l’elemento che valida lato NGINX esegua del codice, e qui la frittata è fatta: Remote Code Execution (RCE). Poiché i privilegi dell’admission controller sono elevati ed hanno accessibilità della rete illimitata, l’esplorazione di questo difetto consente ad un utente malintenzionato di eseguire codice arbitrario e di accedere a tutti i segreti del cluster attraverso i namespace, che potrebbe portare alla completa acquisizione del cluster.

Le vulnerabilità sono state tracciate in cinque diverse CVE, la più grave delle quali ha un punteggio, come detto, di 9.8:

• CVE-2025-24513 (CVSS score: 4.8)
• CVE-2025-24514 (CVSS score: 8.8)
• CVE-2025-1097 (CVSS score: 8.8)
• CVE-2025-1098 (CVSS score: 8.8)
• CVE-2025-1974 (CVSS score: 9.8)

Le versioni del controller Ingress NGINX affette dalla problematica sono la 1.12.1, la 1.11.5 e la 1.10.7. Il suggerimento per quanti utilizzano queste versioni è di provvedere all’aggiornamento, oltre che ad assicurarsi che l’endpoint dell’admission webhook non sia esposto esternamente al cluster.

Si stima che sia affetto più o meno il 40% dei cluster Kubernetes che utilizzano Ingress NGINX, perciò un controllo… Non dovrebbe guastare!