BIND 9: quattro CVE, una può portare a esecuzione di codice

Il 21 ottobre 2026 il Canadian Centre for Cyber Security ha pubblicato l’avviso AV26-1072 su quattro vulnerabilità di BIND 9, il server DNS di Internet Systems Consortium (ISC) molto diffuso su Linux e Unix, sia come resolver interno sia come server autoritativo. Il giorno dopo il CERT.LV, il CERT nazionale della Lettonia, ha ripreso la notizia aggiungendo i punteggi di gravità e le versioni corrette, e heise Security ne ha scritto con un titolo che parla di una falla per introdurre codice nel nameserver.

La più seria è la CVE-2026-94300: secondo il CERT.LV, in determinate condizioni può permettere a un attaccante di eseguire codice arbitrario da remoto. Le altre tre possono fermare il servizio DNS o consumarne le risorse. Nessuna delle fonti riporta, al momento, uno sfruttamento attivo.

Le quattro vulnerabilità

I titoli delle CVE sono quelli dell’avviso canadese; i punteggi CVSS vengono dal CERT.LV.

• CVE-2026-94300 – messaggi GSS-TSIG concorrenti corrompono la memoria. CVSS 8,1. È quella che, secondo il CERT.LV, può portare all’esecuzione di codice in remoto.
• CVE-2026-19630 – esaurimento amplificato delle risorse nell’elaborazione dei messaggi in ingresso. CVSS 7,5.
• CVE-2026-96888 – named può terminare in modo inatteso quando si usa una zona di tipo redirect insieme alla QNAME minimization in modalità strict. CVSS 7,5.
• CVE-2026-97313 – alcune configurazioni RPZ (Response Policy Zone), con determinati schemi di query, possono far terminare il processo in modo inatteso. CVSS 7,5.

Il CERT.LV definisce una delle vulnerabilità «critica» e le altre di gravità alta; il punteggio più elevato che indica, però, è 8,1, che nella scala CVSS corrisponde a una gravità alta. Per le altre tre CVE gli effetti descritti sono il malfunzionamento del server DNS, un consumo eccessivo di CPU e memoria o il denial of service.

Un po’ di contesto per capire chi è esposto. GSS-TSIG è la variante di TSIG basata su GSS-API e Kerberos: in BIND si usa soprattutto per gli aggiornamenti dinamici autenticati, tipici degli ambienti integrati con Active Directory, e si attiva con opzioni come tkey-gssapi-keytab o tkey-gssapi-credential. Le zone redirect servono a dare risposte personalizzate alle query per nomi inesistenti; le RPZ sono il meccanismo con cui un resolver applica liste di blocco, per esempio in un firewall DNS. Le fonti disponibili non dicono se le CVE legate a queste funzioni colpiscano anche i server che non le usano: verificalo nell’avviso di ISC di ciascuna CVE.

Versioni colpite e correzioni

Secondo l’avviso canadese sono colpite:

• BIND 9: dalla 9.11.0 alla 9.18.50 e dalla 9.21.0 alla 9.21.26;
• BIND Supported Preview Edition: dalla 9.11.3-S1 alla 9.18.50-S1 e dalla 9.20.9-S1 alla 9.20.29-S1.

Il CERT.LV cita tra i rami colpiti anche il 9.20 e indica come versioni corrette, che ISC chiede di installare il prima possibile, la 9.20.30 e la 9.21.27. Le fonti disponibili non riportano una versione corretta per il ramo 9.18 né per le Supported Preview Edition, e non dicono quali versioni siano colpite da ciascuna CVE: l’avviso canadese rimanda alla matrice delle vulnerabilità di BIND 9 pubblicata da ISC, che resta il riferimento.

Impatto per le aziende europee e italiane

BIND è presente nei resolver interni di molte aziende, nei server autoritativi di provider e hosting, nelle distribuzioni Linux e in apparati che lo includono. Se il DNS si ferma, si fermano di fatto posta, applicazioni web, VPN e servizi interni, anche quando i server applicativi funzionano. Una corruzione della memoria sfruttabile da remoto è un rischio di livello diverso: il server DNS occupa spesso una posizione privilegiata nella rete, con visibilità su tutte le risoluzioni.

Per la NIS2 i fornitori di servizi DNS rientrano espressamente tra le infrastrutture digitali; in Italia la direttiva è recepita con il D.Lgs. 138/2024. Per gli altri soggetti, un’interruzione del DNS che blocca servizi essenziali può diventare un incidente da valutare per la notifica allo CSIRT Italia dell’ACN. Nella sanità, dove anche i sistemi clinici dipendono dalla risoluzione dei nomi interna, il tema è la continuità operativa.

Cosa fare subito

1. Fai l’inventario dei sistemi che eseguono named: resolver interni, server autoritativi esposti su Internet, apparati che includono BIND. Con named -v vedi la versione installata.
2. Aggiorna alla versione corretta del tuo ramo: 9.20.30 o 9.21.27 secondo il CERT.LV. Per il ramo 9.18 e per le edizioni -S1 consulta l’avviso di ISC. Se usi i pacchetti di una distribuzione Linux, fa fede il bollettino della distribuzione, che spesso porta le correzioni senza cambiare il numero di versione principale.
3. Dai la precedenza ai server che usano GSS-TSIG, RPZ o zone redirect con QNAME minimization strict. Un controllo rapido della configurazione: named-checkconf -p | grep -E 'tkey-gssapi|response-policy|qname-minimization|type redirect'.
4. Riduci l’esposizione: i resolver ricorsivi dovrebbero rispondere solo ai client interni (allow-recursion) e gli aggiornamenti dinamici dovrebbero arrivare solo dai sistemi autorizzati. Sono buone pratiche generali, non soluzioni temporanee indicate dalle fonti: per eventuali workaround fa fede ISC.
5. Rileva: sorveglia arresti e riavvii anomali di named e picchi di CPU e memoria sui server DNS. In termini MITRE ATT&CK, uno sfruttamento rientrerebbe in T1190 (Exploit Public-Facing Application) per l’esecuzione di codice e in T1499.004 (Application or System Exploitation) per il denial of service.

Come aiuta ARXDOME

ARX Shield mostra le vulnerabilità aperte per macchina e per pacchetto, così trovi in fretta i server con versioni di BIND da aggiornare. ARX Expose e ARX Scout dicono quali servizi DNS della tua azienda sono raggiungibili da Internet: il primo dalle fonti pubbliche, il secondo con una verifica autorizzata di porte e servizi. ARX Sentry raccoglie log ed eventi dai server Linux, così un arresto anomalo di named non passa inosservato.

Ultimo aggiornamento: 22 ottobre 2026