Exim Dead.Letter: RCE non autenticata su server mail GnuTLS
Vulnerabilità Dead.Letter (CVE-2026-45185) su Exim 4.97-4.99.2 con GnuTLS: use-after-free in BDAT consente RCE non autenticata e non ha workaround.
Contenuto
Exim ha rilasciato il 12 maggio 2026 la versione 4.99.3 per correggere la vulnerabilità CVE-2026-45185, soprannominata Dead.Letter. Il difetto, un use-after-free nel parser BDAT attivabile su build GnuTLS, consente esecuzione remota di codice non autenticata. Non esistono workaround: l’unica difesa è l’aggiornamento immediato, un’urgenza massima per i server Debian e Ubuntu esposti direttamente su Internet.
- Le versioni interessate sono Exim dalla 4.97 alla 4.99.2 compilato con
USE_GNUTLS=yes; le build con OpenSSL non sono colpite. - L’exploit si attiva quando un client invia un
close_notifyTLS prima del completamento del trasferimento BDAT, seguito da un byte in chiaro sulla stessa connessione TCP. - Non è richiesta autenticazione, destinatari validi o interazione utente: l’attaccante remoto può ottenere esecuzione di codice arbitrario.
- Non esistono workaround o mitigazioni intermedie; l’unica contromisura è l’aggiornamento alla versione 4.99.3, prioritario su distribuzioni Debian-based.
La sequenza di rete che innesca il use-after-free
Il difetto risiede nel modo in cui Exim gestisce il chunking BDAT del protocollo SMTP quando la sessione TLS è mediata da GnuTLS. Secondo l’advisory diffuso dal progetto Exim e riportato da The Hacker News, la vulnerabilità si manifesta nel corso della gestione del corpo di un messaggio BDAT: un client malevolo invia un alert close_notify sul canale TLS prima che il trasferimento del body sia completato, quindi spedisce un byte finale in chiaro sulla medesima connessione TCP.
Durante lo spegnimento del layer TLS, Exim libera il buffer dedicato al trasferimento crittografato; tuttavia il wrapper ricezione BDAT annidato può ancora elaborare i byte in arrivo. In questa condizione, una chiamata a ungetc() scrive il carattere \n all’interno della regione di memoria già rilasciata, corrompendo i metadati dell’allocatore heap. Da qui deriva il percorso verso l’esecuzione remota di codice, con potenziale compromissione totale del server di posta.
"During TLS shutdown, Exim frees its TLS transfer buffer – but a nested BDAT receive wrapper can still process incoming bytes and end up calling ungetc(), which writes a single character (\n) into the freed region" – Federico Kirschbaum, head of Security Lab at XBOW.
Perché le build GnuTLS sono esposte e le OpenSSL no
La criticità è circoscritta alle build compilate con il flag USE_GNUTLS=yes. Le versioni di Exim dalla 4.97 alla 4.99.2 che adottano questo stack crittografico sono interessate, mentre le build basate su OpenSSL non risentono del problema. La differenza non dipende dalla configurazione a runtime, ma dalla scelta effettuata in fase di compilazione del pacchetto o del binario.
Gli ambienti che utilizzano OpenSSL come provider TLS, incluse build custom o distribuzioni con diverso default, non presentano la superficie di attacco. Al contrario, le distribuzioni Debian-based utilizzano tipicamente GnuTLS come default per Exim, amplificando la portata della minaccia su un segmento molto ampio di server di posta esposti alla rete.
Debian e Ubuntu: il cuore del rischio
La concentrazione del rischio su Debian e Ubuntu non è casuale. Come evidenzia Field Effect, nelle distribuzioni derivate da Debian il pacchetto predefinito di Exim è compilato con GnuTLS, rendendo immediatamente vulnerabili i server aggiornati alle versioni comprese tra la 4.97 e la 4.99.2. La presenza diffusa di Exim su queste piattaforme, spesso esposto direttamente su Internet, trasforma la falla in un vettore di attacco ad alta profondità.
Un eventuale exploit riuscito non si limita all’interruzione del servizio. L’esecuzione remota di codice non autenticata consente di intercettare il flusso di posta elettronica, sottrarre credenziali presenti nei messaggi o nei log, e muoversi lateralmente all’interno della rete a partire dal server compromesso. Al momento della pubblicazione non risulta exploitation attiva confermata in the wild, ma l’assenza di workaround rende ogni istanza non patchata un bersaglio teorico a costo zero per l’attaccante.
Cosa fare adesso
L’unica contromisura efficace è l’aggiornamento alla versione 4.99.3, rilasciata il 12 maggio 2026 dal progetto Exim. Le fonti concordano nel segnalare che non esistono workaround configurabili o mitigazioni temporanee in grado di bloccare il vettore d’attacco, rendendo il patch un’operazione non differibile.
Le priorità operative devono seguire questa sequenza. In primo luogo, verificare se la propria build di Exim utilizza GnuTLS: se il sistema impiega una build OpenSSL, il rischio non si applica. In secondo luogo, identificare tutti i server Debian e Ubuntu esposti su Internet che eseguono una versione compresa tra la 4.97 e la 4.99.2.
In terzo luogo, applicare la 4.99.3 attraverso il gestore pacchetti della distribuzione o ricompilando dal sorgente ufficiale. In quarto luogo, confermare che il processo attivo sia stato ricaricato con il binario corretto, poiché un aggiornamento su disco senza restart del servizio lascia in memoria la versione vulnerabile. L’assenza di scorciatoie rende la disciplina del patching l’unica linea di difesa disponibile.
La disclosure coordinata da XBOW e dal progetto Exim offre agli amministratori un margine di manovra limitato: al momento non risulta alcun proof-of-concept pubblico, ma l’assenza di workaround trasforma ogni ora di ritardo in un aumento misurabile della superficie di attacco. Per le organizzazioni che fanno affidamento su Exim con GnuTLS su Debian o Ubuntu, questo non è un ciclo di patch ordinario: è un evento che richiede intervento immediato perché ogni istanza esposta rimane senza difese fino all’applicazione della 4.99.3.
FAQ
Le build con OpenSSL sono davvero al sicuro?
Sì. L’advisory Exim, riportato da The Hacker News, specifica esplicitamente che le build compilate senza il supporto GnuTLS non sono interessate. Se il proprio Exim è linkato contro OpenSSL, la vulnerabilità non si applica.
È necessario un account valido sul server per sfruttare la vulnerabilità?
No. Secondo Field Effect e il resoconto di The Hacker Wire, l’exploit non richiede autenticazione, destinatari validi o interazione da parte di un utente. Un attaccante di rete non autenticato può raggiungere il server e innescare la catena di corruzione heap.
Esiste una configurazione temporanea che mitighi il rischio in attesa dell’aggiornamento?
No. Sia l’advisory Exim sia l’analisi di Field Effect concordano: non esistono workaround o mitigazioni efficaci se non il passaggio diretto alla versione 4.99.3. Qualsiasi tentativo di limitazione perimetrale riduce l’esposizione ma non elimina il vettore.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://thehackernews.com/2026/05/new-exim-bdat-vulnerability-exposes.html
- https://fieldeffect.com/blog/critical-exim-flaw-gnutls-builds
- https://news.cybertechworld.co.in/index.php/2026/05/12/new-exim-bdat-vulnerability-exposes-gnutls-builds-to-potential-code-execution/
- https://www.thehackerwire.com/exim-critical-rce-use-after-free-in-bdat-parsing/