Nel progetto in fase di sviluppo del controller ingress Kubernetes ingress-nginx sono state identificate quattro vulnerabilit\u00e0 che consentono di eseguire codice malevolo sui server delle piattaforme cloud che utilizzano Kubernetes, ottenendo accesso privilegiato completo al cluster Kubernetes. Questi problemi sono stati classificati con un livello critico di gravit\u00e0 (9.8 su 10). I ricercatori che hanno scoperto le vulnerabilit\u00e0 hanno assegnato il nome in codice IngressNightmare e hanno notato che riguardano 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 gestire l'accesso dalla rete esterna ai servizi all'interno del cluster. Il controller ingress-nginx \u00e8 il pi\u00f9 popolare e viene applicato un 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 collegato al controller kubernetes-ingress, il cui supporto \u00e8 gestito da F5\/NGINX (le vulnerabilit\u00e0 considerate non interessano i progetti sviluppati dagli sviluppatori di NGINX, la menzione di nginx nel nome ingress-nginx \u00e8 legata solo all'utilizzo di nginx come proxy). <\/p>\n Le vulnerabilit\u00e0 consentono a un attaccante non autenticato di eseguire codice nel contesto del controller ingress-nginx, nel caso in cui possa inviare una richiesta al gestore web Admission. Durante la scansione della rete sono stati identificati oltre 6500 cluster Kubernetes vulnerabili, che utilizzano controller vulnerabili pubblicamente con gestori Admission aperti a richieste esterne. <\/p>\n Nella configurazione predefinita, il codice eseguito da un aggressore pu\u00f2 accedere alle impostazioni dell'oggetto Ingress, dove, tra le altre cose, sono memorizzate anche le credenziali per contattare i server Kubernetes, consentendo cos\u00ec di ottenere accesso privilegiato all'intero cluster. Come misura di protezione alternativa, si raccomanda di disabilitare nella configurazione ingress-nginx la funzione \"Validating Admission Controller\". <\/p>\n Il controllore Admission viene eseguito in un ambiente pod separato e svolge l'operazione di verifica degli oggetti ingress in arrivo prima della loro distribuzione. Per impostazione predefinita, il web-handler Admission accetta richieste senza autenticazione dalla rete pubblica. Durante la verifica, il controllore Admission crea una configurazione per il server http nginx basata sui contenuti dell'oggetto ingress ricevuto e ne verifica la correttezza. <\/p>\n Le vulnerabilit\u00e0 identificate consentono di iniettare le proprie impostazioni in nginx inviando un oggetto ingress appositamente formattato direttamente al controller Admission. I ricercatori hanno scoperto che alcune propriet\u00e0 delle richieste di verifica, impostate nel campo \".request.object.annotations\", vengono direttamente iniettate nella configurazione di nginx. La configurazione generata non viene applicata, ma solo testata eseguendo il file \"nginx\" con l'opzione \"-t\". <\/p>\n In particolare, l'inserimento di dati esterni nella configurazione avviene per i parametri \"mirror-target\", \"mirror-host\" (CVE-2025-1098), \"auth-tls-match-cn\" (CVE-2025-1097) e \"auth-url\" (CVE-2025-24514). Ad esempio, nella riga di configurazione \"set $target {{ $externalAuth.URL }};\" anzich\u00e9 \"{{ $externalAuth.URL }}\" viene sostituito l'URL specificato nel parametro \"auth-url\". La correttezza dell'URL non viene controllata. Di conseguenza, un aggressore pu\u00f2 fornire come URL un valore come \"http:\/\/example.com\/#;\\nsettings\" e iniettare le proprie configurazioni nel file di configurazione. <\/p>\n Per eseguire codice arbitrario durante il processo di verifica della configurazione con il comando \"nginx -t\", i ricercatori hanno sfruttato il fatto che, oltre a controllare la sintassi, nginx carica librerie da 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. 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 richieste di grandi dimensioni, nginx memorizza il corpo della richiesta in un file temporaneo, che viene immediatamente eliminato, ma nel file system \"\/proc\" rimane un descrittore di file aperto per questo file. In questo modo, \u00e8 possibile inviare contemporaneamente richieste per mantenere il file temporaneo e avviare la verifica della configurazione, in cui la direttiva \"ssl_engine\" specifica il percorso al descrittore nel file system \"\/proc\". <\/p>\n Affinch\u00e9 il descrittore di file rimanga accessibile per un lungo periodo, \u00e8 possibile impostare il valore \"Content-Length\" nella richiesta a un valore notevolmente maggiore rispetto ai dati effettivamente trasmessi (il server attender\u00e0 la ricezione dei restanti dati). Ulteriore complessit\u00e0 deriva dalla necessit\u00e0 di indovinare il PID del processo e il numero del descrittore di file associato alla libreria condivisa caricata, ma poich\u00e9 nel contenitore di solito viene utilizzato un numero ridotto di processi attivi, i valori necessari vengono indovinati mediante tentativa e errore. In caso di successo e caricamento della libreria condivisa iniettata, l'aggressore pu\u00f2 accedere ai parametri memorizzati all'interno dell'ambiente pod, sufficienti per gestire l'intero cluster.