La community Kubernetes si trova ad affrontare una minaccia seria, identificata come CVE-2026-24512, una vulnerabilità classificata con punteggio CVSS 8.8 che colpisce ingress-nginx, uno dei controller più diffusi per la gestione del traffico in ambienti containerizzati. La falla consente agli attaccanti autenticati di iniettare impostazioni malevoli attraverso il campo rules.http.paths.path delle risorse Ingress, aprendo le porte all’esecuzione di codice arbitrario e all’accesso non autorizzato ai segreti del cluster.
Il problema risiede nel fatto che, nelle installazioni predefinite, il controller ingress-nginx ha accesso a tutti i Secret dell’intero cluster, trasformando una singola compromissione in un potenziale disastro su scala globale. Ciò che rende questa vulnerabilità particolarmente insidiosa è la semplicità con cui può essere sfruttata, tra cui bassa complessità d’attacco, requisiti minimi di privilegi e nessuna interazione necessaria.
Le versioni interessate includono tutte le release precedenti alla v1.13.7 e alla v1.14.3, coprendo quindi una vastissima percentuale di deployment attivi. Inoltre, questa scoperta giunge in un momento delicato, considerando che il progetto ingress-nginx ha annunciato la sua dismissione per marzo 2026, rendendo ancora più urgente la necessità di migrazione verso soluzioni alternative.
Per chi non avesse familiarità con l’ecosistema, ricordiamo che Kubernetes è lo strumento che coordina automaticamente applicazioni che girano su server. In pratica, quando una rete è composta da tante app (per esempio un sito web, un database e vari servizi di supporto), Kubernetes si occupa di farle partire, tenerle in funzione, distribuirle su più computer e riavviarle se qualcosa smette di funzionare. È come un “direttore d’orchestra” che coordina tanti piccoli programmi, assicurandosi che ci siano sempre abbastanza risorse, che il sistema continui a funzionare anche se un server si guasta e che l’app possa crescere o ridursi automaticamente in base al numero di utenti.
Meccanismi di sfruttamento e campagne di attacco attive
Il funzionamento della vulnerabilità CVE-2026-24512 si basa su un’inadeguata validazione degli input nel campo path delle impostazioni Ingress. Gli attaccanti possono inserire direttive nginx malevole che vengono poi elaborate dal server web senza sanitizzazione, permettendo la manipolazione del flusso delle richieste HTTP.
I ricercatori di Datadog Security Labs hanno identificato una campagna attiva di hijacking del traffico web che sfrutta proprio configurazioni nginx compromesse. La tecnica utilizzata prevede l’inserimento di blocchi location malevoli che intercettano richieste legittime e le reindirizzano attraverso server backend controllati dagli attaccanti, mantenendo tutte le intestazioni originali per apparire trasparenti.
I target principali includono domini asiatici, particolarmente i TLD .in, .id, .pe, .bd, .edu, .gov e .th, oltre a infrastrutture di hosting cinesi come il Baota Panel. Gli script automatizzati utilizzati dagli attaccanti (zx.sh, bt.sh, 4zdh.sh, zdh.sh) dimostrano un approccio multi-fase altamente sofisticato.
Il processo va dall’orchestrazione iniziale all’enumerazione dei percorsi di configurazione, dall’iniezione mirata fino all’esfiltrazione delle mappe di configurazione verso server C2. Di particolare interesse è l’uso di connessioni TCP raw quando utility standard come curl non sono disponibili, e la validazione preventiva delle configurazioni tramite nginx -t per minimizzare le interruzioni di servizio.
CVE-2026-24512: strategie di mitigazione e indicatori di compromissione
Se gestisci cluster Kubernetes con ingress-nginx, la priorità assoluta è verificare la versione installata eseguendo il comando kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx. Qualora risultassero attivi pod ingress-nginx, devi immediatamente aggiornare alla versione 1.13.7, 1.14.3 o successive, seguendo la documentazione ufficiale di upgrade.
Nel caso in cui un aggiornamento immediato non sia fattibile, puoi implementare una mitigazione temporanea configurando un validating admission controller che rifiuti tutte le risorse Ingress che utilizzano il path type ImplementationSpecific, bloccando così il vettore d’attacco principale.
Parallelamente, dovresti ispezionare manualmente le configurazioni Ingress esistenti cercando valori anomali nel campo path che contengano caratteri speciali, sequenze di escape o direttive nginx. Per rilevare compromissioni già avvenute, controlla la presenza di domini malevoli noti come xzz.pier46[.]com, ide.hashbank8[.]com e th.cogicpt[.]org nelle configurazioni proxy_pass, e verifica eventuali comunicazioni verso l’IP 158.94.210[.]227, identificato come server C2.
Verso la fine di ingress-nginx su Kubernetes
La scoperta del CVE-2026-24512 è l’ennesimo capitolo di una serie di vulnerabilità critiche che hanno afflitto di recente ingress-nginx, inclusa la catena IngressNightmare (CVE-2025-1974). Questa escalation di problemi di sicurezza ha portato la community Kubernetes a una decisione drastica ma necessaria, ovvero il ritiro definitivo del progetto entro marzo 2026, con conseguente cessazione di tutti gli aggiornamenti di sicurezza e correzioni di bug.
Per le organizzazioni che dipendono da ingress-nginx, questo significa pianificare una migrazione strategica verso alternative più moderne e mantenute, come Traefik, HAProxy Ingress, Ambassador o il gateway API di Kubernetes stesso, che costituisce la direzione futura ufficiale del progetto.
La transizione richiederà tempo e risorse, quindi è fondamentale avviarla subito, parallelamente all’applicazione delle patch per CVE-2026-24512. La complessità architetturale di ingress-nginx, evidenziata dalle difficoltà nel mantenerlo sicuro, suggerisce che soluzioni più semplici e meglio progettate potrebbero offrire vantaggi a lungo termine non solo in termini di sicurezza, ma anche di gestibilità.
