Dead.Letter CVE-2026-45185 : RCE Exim sur builds GnuTLS

Les faits

Le projet Exim a publié la version 4.99.3 le 12 mai 2026 pour corriger CVE-2026-45185, baptisée Dead.Letter par les chercheurs de XBOW qui ont divulgué la vulnérabilité après 90 jours. Il s'agit d'un use-after-free déclenché pendant le traitement du corps des messages SMTP transférés via l'extension BDAT, lorsque la connexion sous-jacente est sécurisée par GnuTLS et non par OpenSSL.

Le scénario d'exploitation est étonnamment simple à mettre en place. Un attaquant ouvre une connexion TLS standard vers le port 25 ou 465 d'un serveur Exim vulnérable, négocie l'extension CHUNKING, commence à envoyer un message via BDAT, puis émet une alerte TLS close_notify avant la fin du transfert et envoie un dernier octet en clair sur la même connexion TCP. Cette séquence pousse Exim à écrire dans une zone mémoire déjà libérée lors du teardown TLS, ce qui produit une corruption de tas exploitable pour de l'exécution de code à distance.

XBOW indique avoir développé un PoC fonctionnel avec l'aide d'un assistant IA pour la phase de fuzzing et de stabilisation du gadget mémoire. La publication détaille la chaîne d'exploitation, depuis l'envoi du paquet jusqu'à l'obtention d'un shell sous l'identité de l'utilisateur Exim, généralement Debian-exim sur les distributions dérivées. L'attaque est non authentifiée, ne nécessite aucune interaction utilisateur, et l'extension CHUNKING ainsi que TLS sont activés par défaut sur la quasi-totalité des installations modernes d'Exim.

Le périmètre touché concerne exclusivement les builds compilés avec USE_GNUTLS=yes, ce qui correspond à la configuration par défaut sur Debian, Ubuntu, et la majorité des distributions Linux gérées par les BOSH ou Chef de communauté. Les builds OpenSSL, plus courants sur Red Hat et CentOS, ne sont pas vulnérables. Une commande exim4 -bV permet de connaître la bibliothèque TLS compilée, sous la ligne Library version.

Exim reste le MTA le plus déployé sur Internet, avec une part de marché estimée à plus de 60 pour cent des serveurs publics selon les derniers comptages de Shadowserver et MX-toolbox. Cela porte la population potentiellement exposée à plusieurs centaines de milliers d'instances Internet-facing, dont une portion non négligeable dans le périmètre français des hébergeurs mutualisés et des fournisseurs de mail professionnel. Le CERT-FR n'a pas encore publié de bulletin dédié au 13 mai, mais une alerte de niveau 2 est attendue selon plusieurs sources concordantes.

La chronologie de la divulgation est révélatrice de la sensibilité du sujet. XBOW affirme avoir signalé la vulnérabilité au mainteneur principal d'Exim le 9 février 2026, qui a confirmé le bug le 17 février et publié le patch en interne le 22 avril. Une fenêtre embargo de trois semaines a été observée pour permettre aux distributions de préparer leurs paquets, ce qui explique la disponibilité rapide des correctifs dans les dépôts Debian, Ubuntu et Arch dès le 12 mai. Les administrateurs RHEL et SUSE qui auraient recompilé Exim avec GnuTLS pour des raisons de licence devront vérifier leur build local.

Aucune exploitation in-the-wild n'est encore documentée au 13 mai 2026, mais l'historique des CVE critiques sur Exim indique une fenêtre d'environ 72 heures entre la publication d'un PoC public et l'apparition de scans massifs. Greynoise a déjà observé une augmentation de 40 pour cent des connexions SMTP suspectes vers des honeypots Exim entre le 12 et le 13 mai, signal précurseur d'une campagne d'exploitation à large échelle.

Le contexte rend la situation préoccupante. Les serveurs mail figurent rarement dans les inventaires de criticité maintenus par les RSSI, alors qu'ils exposent un service réseau historiquement complexe, riche en parsers, et tournant typiquement avec des droits élevés. La précédente vulnérabilité majeure d'Exim, CVE-2023-42115, avait laissé exposée pendant plus de huit mois une fraction significative du parc Internet avant qu'un patch n'arrive aux administrateurs concernés.

Impact et exposition

Toute organisation exploitant un serveur Exim compilé contre GnuTLS et exposé sur Internet en SMTP ou Submission est exposée. L'exécution de code obtenue tourne sous l'utilisateur Exim, ce qui donne accès aux files locales de mail, aux configurations sender-rewrite, et selon le durcissement aux sockets locaux d'autres services. Dans une architecture standard de relais mail mutualisé, une compromission d'un noeud Exim ouvre la voie à de l'interception de mail, du forwarding malveillant, et à du pivot vers les Maildir des utilisateurs locaux.

Recommandations

• Identifier les serveurs Exim avec exim4 -bV et vérifier la mention GnuTLS dans la Library version.
• Mettre à jour vers Exim 4.99.3 ou supérieur dès la disponibilité du paquet dans votre distribution.
• En attendant le patch, désactiver l'extension CHUNKING via la directive chunking_advertise_hosts = en configuration Exim.
• Surveiller les logs mainlog pour les patterns de séquence BDAT suivis d'une déconnexion anormale et d'un dernier octet.
• Considérer une bascule temporaire vers OpenSSL si l'organisation gère ses propres builds Exim.