CVE-2025-1974 — IngressNightmare (ingress-nginx)

Introduzione

Questo documento presenta un'analisi della vulnerabilità CVE-2025-1974, che riguarda il componente ingress-nginx (validating admission controller) per Kubernetes.
CVE-2025-1974 è una vulnerabilità critica (CVSS 3.1 9.8), che consiste in un Remote Code Execution (RCE) non autenticato nel contesto del processo ingress-nginx. Durante un attacco, un malintenzionato con accesso alla pod network (o in grado di inviare un AdmissionReview al validating webhook) può ottenere l'esecuzione di codice arbitrario nel pod del controller, portando potenzialmente alla divulgazione di Secrets e alla compromissione del cluster.

Ingress-nginx è uno dei controller Ingress più diffusi in Kubernetes (le stime indicano un utilizzo in decine di percentuali dei cluster), quindi l'impatto pratico della vulnerabilità è molto elevato. Descrizione, analisi tecnica e raccomandazioni ufficiali per le correzioni sono state pubblicate da Kubernetes, dai ricercatori di Wiz e da vari blog di vendor.

Scopo del report

Analizzare passo dopo passo CVE-2025-1974 e preparare i materiali necessari per un write-up:

Raccolta e strutturazione dei materiali. Raccogliere advisory ufficiali, write-up di ricerca e analisi dei vendor; evidenziare i dettagli tecnici chiave e le direzioni del PoC.
Comprendere l'essenza della vulnerabilità e il suo impatto. Spiegare la root cause, la catena d'attacco e le possibili conseguenze (RCE → divulgazione di Secrets → compromissione del cluster).
Determinare CPE e condizioni di configurazione. Elencare versioni/pacchetti e configurazioni di Kubernetes/ingress-nginx per cui la vulnerabilità è rilevante.
Fornire raccomandazioni per test sicuri in laboratorio e per minimizzare il rischio durante verifiche su larga scala.

⚠️ Disclaimer

Questa ricerca è condotta esclusivamente a scopo educativo ed etico ed è rivolta ad ambienti di test/controllati.
In nessun caso eseguire exploit/PoC contro cluster altrui o istanze pubblicamente accessibili senza autorizzazione scritta del proprietario. Pubblicare un PoC completamente funzionante e "weaponized" in forma aperta aumenta notevolmente il rischio di abusi — nella parte pubblica è meglio fornire un safe-PoC e la metodologia. (Anche gli advisory ufficiali e i vendor sottolineano la cautela nella diffusione degli exploit).

CPE e condizioni di configurazione

cpe:2.3:a:kubernetes:ingress-nginx_controller:<version> — versioni vulnerabili di ingress-nginx (negli advisory sono indicate versioni specifiche; aggiornare i valori al momento della pubblicazione finale).
Fornitori/distribuzioni che includono il controller vulnerabile:
- Distribuzioni RKE2 / Rancher con ingress-nginx antecedente alle versioni patch indicate.
- Versioni di Harvester che utilizzano ingress-nginx vulnerabile (la KB del vendor contiene build interessate specifiche).
- Cluster personalizzati in cui ingress-nginx è installato separatamente (Helm chart/manifest) — verificare le versioni di chart/image.

Condizioni di configurazione per cui la vulnerabilità è rilevante:

Versione vulnerabile di ingress-nginx (antecedente al rilascio/patch indicato negli advisory). I numeri di versione esatti si trovano in NVD e negli advisory dei vendor.
Validating admission webhook accessibile dall'esterno della pod network — se il webhook è accessibile dall'esterno (ad esempio endpoint pubblico, provider che ha erroneamente esposto il servizio), l'exploit può essere eseguito da remoto. Wiz e altri ricercatori hanno segnalato numerosi casi di esposizione pubblica.
Assenza di NetworkPolicy / isolamento della pod network: se un malintenzionato può inviare richieste da un pod nella rete del cluster (pod compromesso), ciò è sufficiente per lo sfruttamento.
Assenza di validazioni/ACL aggiuntivi prima dell'admission controller: filtri aggiuntivi/autenticazione del proxy di ingresso possono ridurre il rischio.
Presenza nel container ingress-nginx di un service account con permessi estesi e accesso ai Secrets — per impostazione predefinita, il controller spesso monta un serviceAccount con permessi estesi; ciò aumenta l'impatto in caso di sfruttamento riuscito.

Dettagli della vulnerabilità

Riassunto breve.
La vulnerabilità è stata scoperta nel componente Validating Admission Controller del controller Ingress-NGINX ed è legata al modo in cui questo componente genera e verifica la configurazione temporanea di NGINX sulla base degli Ingress / AdmissionReview in arrivo. Durante l'elaborazione, il controller genera nginx.conf ed esegue un controllo della configurazione (nginx -t). A causa di una sanificazione insufficiente dei campi di Ingress/AdmissionReview, un attaccante può iniettare frammenti appositamente predisposti che finiscono nella configurazione generata, portando all'esecuzione di comandi all'interno del processo del controller — ovvero a un'esecuzione remota di codice (RCE) nel pod di ingress-nginx.

Punti tecnici principali

Punto di ingresso. Gli oggetti AdmissionReview/Ingress in arrivo, ricevuti dal validating webhook del controller, diventano dati di origine per la generazione della configurazione NGINX (inclusi campi di annotazioni, impostazioni backend, ecc.).
Meccanismo di sfruttamento. Un Ingress malevolo o un AdmissionReview diretto può inserire stringhe controllate nei template/frammenti di configurazione. Durante la verifica/caricamento di questo nginx.conf, il processo di verifica (nginx -t) e le successive operazioni sul file di configurazione possono portare all'esecuzione di codice arbitrario, alla scrittura/esecuzione di file o all'esecuzione di comandi nel contesto del controller.
Condizioni necessarie. Per uno sfruttamento riuscito sono necessari: versione vulnerabile di ingress-nginx; possibilità di inviare un AdmissionReview al validating webhook (accesso dalla pod network o accesso di rete diretto); assenza di misure compensative — NetworkPolicy, restrizioni RBAC o autenticazione aggiuntiva del webhook. In alcuni scenari, l'elusione dei permessi Create/Update è possibile inviando un AdmissionReview appositamente costruito direttamente al webhook.

admission

Perché è pericoloso — conseguenze dello sfruttamento

Uno sfruttamento riuscito consente l'esecuzione di codice nel container ingress-nginx, che di solito permette di:

ottenere il token del serviceAccount del controller e accedere all'API Kubernetes;
leggere Secrets e altre informazioni riservate nei namespace accessibili;
creare/modificare risorse del cluster ed estendere l'accesso (escalation dei privilegi, lateral movement);
in alcuni casi — la compromissione totale del cluster.

Osservazioni comportamentali e di rilevamento

Durante il funzionamento normale, di solito non c'è flusso di richieste verso l'Admission Controller — il validating webhook è un componente interno che opera all'interno del cluster. Durante lo sfruttamento si osserva un'anomalia: sulla mappa di rete (ad esempio Luntry) compaiono connessioni in entrata verso ingress-nginx-controller-admission e il servizio ingress-nginx-controller da origini non standard (nei report, da container come alpine), cosa che non dovrebbe accadere durante il funzionamento normale.
L'analisi della mappa di rete del cluster fornisce una visione delle interazioni tra i microservizi; selezionando il Deployment ingress-nginx nel namespace, si possono vedere le connessioni in entrata/uscita. La comparsa di connessioni in entrata verso l'admission-endpoint al momento dell'attacco è un chiaro indicatore di compromissione.
Per rilevare tentativi di sfruttamento, è utile monitorare: richieste POST al validating webhook, creazione di oggetti Ingress atipici, chiamate a nginx -t e riavvii improvvisi del controller, nonché operazioni inaspettate di scrittura di file da parte del processo ingress-nginx.

Contesto: cos'è il controller Ingress NGINX e perché è importante

Ingress-NGINX è uno dei controller Ingress più utilizzati in Kubernetes (ampiamente impiegato per organizzare l'accesso esterno ai servizi). Il controller funge da proxy inverso: riceve il traffico esterno e lo inoltra ai Service/Pod corrispondenti in base a un insieme di regole Ingress. Il progetto Ingress-NGINX gode di grande popolarità e ha una quota di installazione significativa nei cluster accessibili via Internet.

Ingress-NGINX viene citato nella documentazione di Kubernetes come esempio di riferimento di controller Ingress. Secondo le stime, una parte significativa dei cluster pubblici lo utilizza; alcune ricerche indicano che circa il 41% dei cluster accessibili pubblicamente utilizza Ingress-NGINX. È proprio a causa dell'ampia diffusione e del ruolo centrale nel routing del traffico che le vulnerabilità in questo componente hanno un elevato impatto pratico.

Perché il validating webhook diventa un vettore d'attacco conveniente

Per impostazione predefinita, il validating webhook del controller è accessibile all'interno dello spazio di rete di Kubernetes e spesso non richiede autenticazione aggiuntiva quando si accede al suo indirizzo (ad esempio validate.nginx.ingress.kubernetes.io). Ciò lo rende facile da raggiungere dall'interno del cluster.
La combinazione: ampia diffusione del controller + accessibilità di rete + permessi potenzialmente estesi del service account = combinazione critica che fornisce un percorso efficace per la compromissione.
Nella pratica, ottenere un "primo punto d'ingresso" in un cluster non è così difficile: le applicazioni spesso contengono vulnerabilità che portano alla compromissione di un singolo container; successivamente, l'attaccante da quel container può contattare i webhook interni. Inoltre, vulnerabilità sfruttabili come SSRF nelle applicazioni web vengono spesso utilizzate per avviare richieste all'interno della rete del cluster e coinvolgere tali webhook.

Descrizione della catena d'exploit (riassuntiva)

L'attaccante ottiene la possibilità di inviare richieste nella pod network o di accedere direttamente al validating webhook.
Viene creato un Ingress / AdmissionReview appositamente predisposto, in cui determinati campi contengono stringhe dannose che non hanno subito un'adeguata filtrazione.
Il controller genera nginx.conf sulla base di questi input ed esegue nginx -t / altre operazioni di verifica.
I frammenti iniettati portano all'esecuzione di comandi/script o alla scrittura/esecuzione di file nel contesto del processo del controller.
Ottenuta l'esecuzione, l'attaccante estrae il token del serviceAccount, accede all'API Kubernetes e prosegue con lo spostamento laterale e l'escalation nel cluster.

Osservazioni sulla compatibilità con altre vulnerabilità

Tali vulnerabilità sono particolarmente pericolose se combinate con altri difetti: un pod compromesso (o SSRF in un'applicazione pubblica) + un validating webhook esposto offrono un'alta probabilità di compromissione totale. Pertanto, l'analisi degli incidenti deve considerare la catena di dipendenze e i potenziali vettori, non solo la versione di ingress-nginx.

CVE-2025-1974

Più Popolari