Il 24 marzo 2025 il team di ricerca di Wiz ha divulgato cinque vulnerabilità critiche nell'Ingress NGINX Controller per Kubernetes, raggruppate sotto il nome IngressNightmare. La più grave, CVE-2025-1974 con punteggio CVSS 9.8, consente esecuzione remota di codice non autenticato sfruttando un errore architetturale: l'admission controller, componente che dovrebbe essere raggiungibile solo dall'API Server di Kubernetes, è invece accessibile di rete senza autenticazione. Oltre 6.500 cluster esposti pubblicamente sono a rischio immediato, con circa il 43% degli ambienti cloud risultato vulnerabile.
- CVE-2025-1974 (CVSS 9.8) consente RCE non autenticato a un attaccante con accesso alla pod network, senza richiedere credenziali
- L'attacco sfrutta l'admission controller esposto di rete per design, violando il threat model di Kubernetes che presuppone accesso esclusivo dall'API Server
- Oltre 6.500 cluster sono esposti pubblicamente; circa il 43% degli ambienti cloud è vulnerabile al gruppo IngressNightmare
- Le versioni patched sono la 1.12.1, la 1.11.5 e la 1.10.7; la vulnerabilità non impatta il prodotto distinto NGINX Ingress Controller
Il meccanismo: quando l'admission controller diventa porta di servizio
L'ingresso malevolo passa attraverso un componente che, per sua natura, detiene privilegi elevati. L'admission controller di Ingress NGINX valida gli oggetti ingress prima del deployment per garantire che la configurazione NGINX risultante sia corretta. Secondo il threat model di Kubernetes, questo componente dovrebbe ricevere richieste esclusivamente dall'API Server. Invece, per design, l'admission controller è accessibile di rete senza autenticazione.
Un attaccante con presenza nella pod network — condizione che si verifica in ambienti multi-tenant compromessi o container violati — può inviare direttamente oggetti ingress malevoli, ovvero AdmissionReview requests, all'admission controller. Questi oggetti iniettano configurazione NGINX arbitraria, che a sua volta carica librerie condivise compromesse per ottenere esecuzione di codice con i privilegi del service account dell'ingress controller.
"Exploitation of these vulnerabilities leads to unauthorized access to all secrets stored across all namespaces in the Kubernetes cluster by attackers, which can result in cluster takeover"
— Wiz, report condiviso con The Hacker News
Dal singolo pod al controllo dell'intero cluster
La catena di attacco non si ferma all'esecuzione di codice nel contesto del controller. CVE-2025-1974 può essere concatenata con altre quattro vulnerabilità del gruppo IngressNightmare per completare il cluster takeover. Le altre quattro — CVE-2025-24513 (CVSS 4.8), CVE-2025-24514 (CVSS 8.8), CVE-2025-1097 (CVSS 8.8) e CVE-2025-1098 (CVSS 8.8) — riguardano injection di configurazione tramite annotazioni specifiche negli oggetti ingress.
Il Kubernetes Security Response Committee ha confermato che CVE-2025-1974 è proprio il tassello che abilita il cluster takeover quando concatenata con le altre, senza richiedere credenziali o accesso amministrativo. Il passaggio dalla compromissione del controller all'accesso a tutti i secret in tutti i namespace è reso possibile dai privilegi intrinseci del service account, normalmente necessari per la funzione ma qui convertiti in veicolo di escalation.
Il dossier non specifica se CVE-2025-1974 sia sfruttabile in modo standalone per il cluster takeover completo, o se la concatenazione sia sempre necessaria. Non emerge inoltre se attacchi in the wild siano stati osservati al momento della divulgazione.
La superficie di attacco: numeri da incubo
La ricerca di Wiz ha identificato oltre 6.500 cluster con l'admission controller esposto direttamente a Internet, configurazione che trasforma ogni pod compromesso in potenziale punto di ingresso per il takeover completo. Il dato di circa il 43% degli ambienti cloud vulnerabili indica una diffusione di massa che supera il perimetro dei deployment mal configurati isolati.
La criticità risiede nella combinazione di tre fattori: esposizione di rete di un componente con privilegi elevati, assenza di autenticazione, e posizione architetturale che lo rende implicitamente attendibile dal resto del piano di controllo. È questo intreccio a spiegare perché una singola falla design — non un bug di implementazione nel codice NGINX — produca impatto strutturale su migliaia di cluster.
La distinzione che salva: NGINX Ingress Controller non è toccato
Un punto che il dossier documenta con chiarezza: le vulnerabilità non impattano il prodotto distinto NGINX Ingress Controller, implementazione differente gestita da un altro vendor. La confusione tra i due nomi — Ingress NGINX Controller e NGINX Ingress Controller — è ricorrente nella pratica operativa, ma qui ha conseguenze concrete per il patching. Team che controllino la propria versione dell'implementazione corretta evitano azioni superflue; chi invece gestisca il prodotto vulnerabile senza riconoscerlo rimane esposto.
Perché è importante
Il dossier non specifica misure correttive dettagliate al di là delle versioni patched. La fonte indica due direttrici: limitare l'accesso all'admission controller esclusivamente al Kubernetes API Server, e disabilitare l'admission controller se non necessario per l'operatività del cluster. Il brief non documenta procedure di verifica della configurazione attuale, strumenti di rilevamento, o tempistiche di rollout suggerite.
Il dossier non dettaglia inoltre se versioni precedenti alla linea 1.10.x siano vulnerabili o semplicemente fuori supporto, né fornisce la data esatta di responsible disclosure. Non è chiaro infine quanti cluster siano stati effettivamente compromessi al momento della pubblicazione.
Ciò che il documento rende evidente è il divario tra il modello di sicurezza presupposto da Kubernetes — admission controller isolato e attendibile — e la realtà di deployment dove questo componente è esposto come servizio di rete generico. È un caso di sicurezza architetturale versus sicurezza implementativa: il codice funziona come documentato, ma il design viola il threat model della piattaforma.
Domande e risposte
Ingress NGINX Controller e NGINX Ingress Controller sono la stessa cosa?
No. Sono implementazioni differenti. Il dossier specifica esplicitamente che le vulnerabilità IngressNightmare non impattano il prodotto distinto NGINX Ingress Controller.
Perché il punteggio CVSS è 9.8 anche per il gruppo di vulnerabilità?
Secondo la fonte, il punteggio CVSS 9.8 si applica sia a CVE-2025-1974 individualmente sia al gruppo IngressNightmare nel complesso, riflettendo la gravità massima della catena di attacco.
L'attacco richiede compromissione preliminare di un pod?
Sì. Il prerequisito documentato è l'accesso alla pod network, che può derivare da un container già compromesso o da altra presenza nell'ambiente cluster.
Le informazioni sono basate sull advisory citata e aggiornate al momento della pubblicazione.
Fonti
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.