Nel progetto in sviluppo del controller ingress di Kubernetes ingress-nginx sono state identificate quattro vulnerabilit\u00e0 che consentono l'esecuzione di codice malevolo sui server dei sistemi cloud che utilizzano la piattaforma Kubernetes, ottenendo cos\u00ec accesso privilegiato completo al cluster Kubernetes. Questi problemi sono stati classificati con un livello di pericolo critico (9.8 su 10). I ricercatori che hanno scoperto le vulnerabilit\u00e0 hanno assegnato loro il nome in codice IngressNightmare e hanno notato che le vulnerabilit\u00e0 interessano circa il 43% degli ambienti cloud. Le vulnerabilit\u00e0 sono state corrette nelle versioni ingress-nginx 1.11.5 e 1.12.1. <\/p>\n
Il controller ingress funge da gateway ed \u00e8 utilizzato in Kubernetes per organizzare l'accesso dalla rete esterna ai servizi all'interno del cluster. Il controller ingress-nginx \u00e8 il pi\u00f9 popolare e applica server<\/a> NGINX per il forwarding delle richieste al cluster, la gestione delle richieste esterne e il bilanciamento del carico. Il progetto Kubernetes fornisce controller ingress di base per AWS, GCE e nginx, quest'ultimo non \u00e8 in alcun modo collegato al controller kubernetes-ingress, il cui supporto \u00e8 gestito dall'azienda F5\/NGINX (le vulnerabilit\u00e0 discusse non riguardano i progetti sviluppati dagli sviluppatori di NGINX, il riferimento a nginx nel nome ingress-nginx \u00e8 legato solo all'uso di nginx come proxy). <\/p>\n Le vulnerabilit\u00e0 consentono a un attaccante non autenticato di eseguire codice nel contesto del controller ingress-nginx, avendo la possibilit\u00e0 di inviare una richiesta al processore web Admission. Durante la scansione della rete sono stati identificati oltre 6500 cluster Kubernetes vulnerabili che utilizzano controller vulnerabili pubblicamente accessibili con un processor Admission aperto alle richieste esterne. <\/p>\n Nella configurazione predefinita, il codice eseguito dall'attaccante pu\u00f2 accedere alle impostazioni dell'oggetto Ingress, in cui sono memorizzate, tra l'altro, le credenziali per accedere ai server Kubernetes, consentendo cos\u00ec un accesso privilegiato a tutto il cluster. Come misura di sicurezza, si raccomanda di disabilitare nella configurazione ingress-nginx la funzione \u00abValidating Admission Controller\u00bb. <\/p>\n Il controller Admission viene eseguito in un ambiente pod separato e verifica gli oggetti ingress in entrata prima della loro distribuzione. Per impostazione predefinita, il processore web Admission accetta richieste senza autenticazione dalla rete pubblica. Durante la verifica, il controller Admission crea una configurazione per il server http nginx basata sul contenuto dell'oggetto ingress ricevuto e ne controlla la correttezza. <\/p>\n Le vulnerabilit\u00e0 scoperte consentono di inserire le proprie impostazioni in nginx inviando un oggetto ingress specificamente formattato direttamente al controllore Admission. I ricercatori hanno scoperto che alcune propriet\u00e0 delle richieste di verifica, impostate nel campo \u00ab.request.object.annotations\u00bb, vengono inserite direttamente nella configurazione di nginx. Tuttavia, la configurazione generata non viene applicata, ma solo testata eseguendo il file eseguibile \u00abnginx\u00bb con l'opzione \u00ab-t\u00bb. <\/p>\n In particolare, l'inserimento di dati esterni nella configurazione avviene per i parametri \u00abmirror-target\u00bb, \u00abmirror-host\u00bb (CVE-2025-1098), \u00abauth-tls-match-cn\u00bb (CVE-2025-1097) e \u00abauth-url\u00bb (CVE-2025-24514). Ad esempio, nella riga di configurazione \u00abset $target {{ $externalAuth.URL }};\u00bb al posto di \u00ab{{ $externalAuth.URL }}\u00bb viene inserito l'URL specificato nel parametro \u00abauth-url\u00bb. La correttezza dell'URL non viene verificata. Pertanto, un attaccante pu\u00f2 inviare come URL un valore del tipo \u00abhttp:\/\/example.com\/#;\nsettings\u00bb e inserire le proprie impostazioni nel file di configurazione. <\/p>\n Per eseguire codice arbitrario durante il processo di verifica della configurazione con il comando \u00abnginx -t\u00bb, i ricercatori hanno sfruttato il fatto che oltre a controllare la sintassi, nginx carica librerie con moduli e apre file menzionati nella configurazione per valutarne la disponibilit\u00e0. Tra l'altro, durante l'elaborazione della direttiva ssl_engine, viene caricata la libreria condivisa specificata nella direttiva per SSL<\/a>-il motore. <\/p>\n Per caricare la propria libreria sul server Kubernetes, i ricercatori hanno sfruttato (CVE-2025-1974) il fatto che durante l'elaborazione di grandi richieste nginx salva il corpo della richiesta in un file temporaneo, che viene subito eliminato, ma nel file system \u00ab\/proc\u00bb rimane un descrittore di file aperto per questo file. In questo modo, \u00e8 possibile inviare simultaneamente richieste per salvare il file temporaneo e avviare la verifica della configurazione in cui, nella direttiva \u00abssl_engine\u00bb, \u00e8 specificato il percorso al descrittore nel file system \u00ab\/proc\u00bb. <\/p>\n Per fare in modo che il descrittore di file rimanga accessibile per lungo tempo, il valore «Content-Length» nella richiesta pu\u00f2 essere impostato su un valore deliberatamente maggiore rispetto ai dati effettivamente trasmessi (il server attender\u00e0 il ricevimento dei restanti dati). Un'ulteriore complessit\u00e0 \u00e8 la necessit\u00e0 di indovinare il PID del processo e il numero del descrittore di file associato alla libreria condivisa caricata, ma poich\u00e9 in un container di solito viene utilizzato un numero minimo di processi attivi, i valori necessari vengono indovinati attraverso tentativi successivi. In caso di successo e caricamento della libreria condivisa iniettata, l'attaccante pu\u00f2 accedere ai parametri memorizzati all'interno dell'ambiente pod, sufficienti per controllare l'intero cluster.