Exim: RCE Dead.Letter in GnuTLS, aggiornare subito

CVE-2026-45185 colpisce Exim con GnuTLS: use-after-free nel parser SMTP BDAT consente RCE senza login. Non esistono workaround, serve la 4.99.3.

Contenuto

Exim ha rilasciato il 12 maggio 2026 la versione 4.99.3 per correggere la vulnerabilità CVE-2026-45185, una use-after-free nel parser del comando SMTP BDAT che consente esecuzione remota di codice sui server compilati con GnuTLS. La falla, ribattezzata Dead.Letter, è raggiungibile senza autenticazione né destinatari validi e non ammette workaround temporanei: l'upgrade è l'unica difesa possibile.

Punti chiave

La versione correttiva è la 4.99.3; sono interessate le release dalla 4.97 alla 4.99.2 compilate esclusivamente con USE_GNUTLS=yes.
Il trigger richiede un TLS close_notify durante un trasferimento BDAT attivo, seguito da un byte in cleartext sulla stessa connessione TCP.
Un singolo byte scritto tramite ungetc() su un buffer TLS già liberato corrompe i metadati dell'heap allocator, aprendo alla RCE.
Non esistono mitigazioni di configurazione; la falla è pre-autenticazione e non richiede credenziali o interazione umana.

La catena del crash: close_notify, BDAT e heap corruption

Il bug si innesca durante la gestione del comando BDAT, usato nel chunking SMTP per trasferire il corpo del messaggio in blocchi. Se un client invia un alert TLS close_notify prima che il trasferimento sia completo, Exim libera il buffer dedicato alla sessione GnuTLS. Tuttavia, un wrapper BDAT annidato può ancora accettare byte in arrivo e invocare ungetc(), scrivendo un carattere in memoria già deallocata.

Quel singolo byte finisce sui metadati interni dell'heap allocator di Exim, corrompendone la struttura e aprendo la strada all'esecuzione arbitraria di codice. Il ricercatore Federico Kirschbaum di XBOW Security, che ha scoperto la falla il 1° maggio 2026 e l'ha segnalata al team di sviluppo, ha descritto la sequenza con precisione chirurgica.

"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; that one-byte write lands on Exim's allocator metadata, corrupting the allocator's internal shape." - Federico Kirschbaum, XBOW Security (via The Hacker News)

L'avviso di sicurezza di Exim, riportato da The Hacker News, conferma la sequenza esatta: "The vulnerability is triggered during BDAT message body handling when a client sends a TLS close_notify alert before the body transfer is complete, and then follows up with a final byte in cleartext on the same TCP connection." Questa concatenazione forza il server a riutilizzare un puntatore stale, con conseguenze imprevedibili sulla stabilità del processo.

Perché GnuTLS espone e OpenSSL no

La vulnerabilità interessa soltanto le build compilate con USE_GNUTLS=yes, una scelta comune nelle distribuzioni Debian e Ubuntu che preferiscono GnuTLS per compatibilità con le policy di licenza del sistema. Le build basate su OpenSSL non sono toccate, perché gestiscono il ciclo di vita del buffer TLS in modo diverso durante il teardown della connessione.

Per gli amministratori, questo significa che non basta controllare la versione di Exim: è necessario verificare la configurazione di compilazione attiva. Se il banner o i log indicano l'uso di GnuTLS, il server è potenzialmente vulnerabile alla sequenza di attacco anche se gira una release recente compresa tra la 4.97 e la 4.99.2.

Le installazioni enterprise che gestiscono flussi di posta autonomi sono particolarmente a rischio. Un attaccante può colpire il server prima ancora della fase di autenticazione, senza bisogno di un account valido o di un destinatario esistente nel dominio. La compromissione del servizio di posta può quindi derivare da una singola connessione TCP opportunamente orchestrata.

Il debito del 2017: quando il parser BDAT si era già rotto

La gravità del caso è amplificata da una regressione storica. Un use-after-free quasi identico nel parser BDAT era già stato corretto nel 2017, evidenziando un debito tecnico che il codice di gestione del chunking SMTP non è riuscito a cancellare del tutto. La ricomparsa di una falla di memoria nello stesso sottosistema suggerisce che le modifiche successive hanno rimosso o aggirato i controlli introdotti quasi un decennio fa.

Il maintainer Exim ha accettato la segnalazione responsabile il 1° maggio 2026 e ha impiegato undici giorni per preparare e rilasciare la versione 4.99.3, una timeline relativamente rapida che tuttavia non lascia spazio a workaround intermedio. L'assenza di mitigazioni temporanee rende l'aggiornamento un passaggio obbligatorio e non rimandabile per ogni installazione basata su GnuTLS.

L'advisory ufficiale, come riportato da The Hacker News, descrive la correzione così: "The fix ensures that the input processing stack is cleanly reset when a TLS close notification is received during an active BDAT transfer, preventing the stale pointers from being used." Si tratta di un intervento mirato che ripristina la coerenza dello stack di input senza alterare la logica generale del chunking.

Da maggio a maggio: la disclosure in undici giorni

Federico Kirschbaum di XBOW Security ha inviato la segnalazione al team Exim il 1° maggio 2026. L'advisory pubblico e il rilascio della versione 4.99.3 sono arrivati il 12 maggio 2026, a distanza di undici giorni. Sebbene la rapidità della risposta sia encomiabile, il lasso di tempo ha lasciato gli amministratori senza alcuna contromisura praticabile, rendendo l'intervallo particolarmente pericoloso per i server di posta esposti direttamente su Internet.

Debian e Ubuntu: il cuore del rischio enterprise

Le distribuzioni Debian e Ubuntu rappresentano il perimetro più esposto in ambito enterprise, essendo le più inclini a compilare Exim con GnuTLS anziché OpenSSL. Field Effect, vendor MDR che ha analizzato l'impatto aziendale della falla, sottolinea che l'assenza di workaround temporanei impone agli amministratori una corsa contro il tempo per aggiornare i server di posta interni ed esterni.

Non è disponibile una stima precisa del numero di server Exim con GnuTLS esposti pubblicamente, né una data certa per l'arrivo dei pacchetti patchati nei repository Debian e Ubuntu. Gli amministratori devono quindi verificare autonomamente la disponibilità dell'aggiornamento nei rispettivi canali di distribuzione, senza attendere notifiche automatiche.

Cosa fare adesso

Aggiornare immediatamente a Exim 4.99.3 su ogni server che gestisce posta in ingresso, verificando che il pacchetto distribuito dalla propria distro contenga già la patch ufficiale.
Controllare la compilation flag USE_GNUTLS: se attiva, l'installazione è a rischio; le build con OpenSSL non necessitano di intervento per questa specifica falla.
Non affidarsi a restrizioni SMTP, ACL o filtri firewall come mitigazione: la vulnerabilità è pre-autenticazione e non richiede destinatari validi, rendendo inutile ogni blocco applicativo tradizionale.
Monitorare i log delle connessioni SMTP per pattern anomali di interruzione TLS durante sessioni BDAT, segnalandoli al CERT di riferimento in attesa del completamento degli upgrade.

La vicenda Dead.Letter conferma che le vulnerabilità di memoria nei parser di protocollo legacy possono risorgere con effetti devastanti quando il debito tecnico non viene estirpato alla radice. Per Exim, la gestione del chunking SMTP si è rivelata due volte un campo minato. Gli amministratori non possono fare altro che aggiornare e verificare la propria catena di compilazione, consapevoli che ogni istante di ritardo espone il server a una compromissione totale e silenziosa.

Domande e risposte

Perché solo le build con GnuTLS sono vulnerabili?: La falla dipende dal modo in cui GnuTLS gestisce il rilascio del buffer TLS durante il shutdown della connessione. Le build compilate con OpenSSL gestiscono il teardown in modo diverso e non presentano il percorso di memoria che consente il write-after-free.
È possibile mitigare la minaccia senza aggiornare Exim?: No. Fonti multiple, incluso l'advisory ufficiale e l'analisi di Field Effect, concordano nell'affermare che non esistono workaround di configurazione o regole firewall in grado di bloccare l'attacco, essendo pre-autenticazione.
Il bug del 2017 e Dead.Letter sono tecnicamente identici?: Non è confermato che siano identici al byte: il brief redazionale parla di un use-after-free quasi identico già corretto nel 2017 nel medesimo parser BDAT. La ricorrenza evidenzia una fragilità strutturale persistente nel codice di gestione del chunking SMTP.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.