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:

1. 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.
2. 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).
3. Determinare CPE e condizioni di configurazione. Elencare versioni/pacchetti e configurazioni di Kubernetes/ingress-nginx per cui la vulnerabilità è rilevante.
4. 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:

1. 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.
2. 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.
3. 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.
4. Assenza di validazioni/ACL aggiuntivi prima dell'admission controller: filtri aggiuntivi/autenticazione del proxy di ingresso possono ridurre il rischio.
5. 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.

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.