A critical unauthenticated remote code execution vulnerability in Exim, tracked as CVE-2026-45185 and nicknamed Dead.Letter, was published on 12 May 2026. It carries a CVSS score of 9.8 and affects every Exim build from version 4.97 to 4.99.2 that uses GnuTLS as its TLS library. A fix is available in version 4.99.3. If your mail server runs Exim on Debian or Ubuntu, you need to act now.
Researchers disclosed a use-after-free flaw in Exim's BDAT message body parsing, triggered during a specific TLS shutdown sequence. The issue sits in how Exim handles the interaction between GnuTLS session teardown and the SMTP state machine, according to CyCognito's technical analysis. When a client sends a TLS close_notify alert before completing the message body transfer, then sends a final cleartext byte on the same TCP connection, Exim writes into a memory buffer that was already freed during TLS teardown. That heap corruption gives an attacker the ability to execute arbitrary code with the privileges of the Exim process.
No authentication is required. An attacker needs only to open a TLS connection and use the CHUNKING SMTP extension, both standard capabilities available to any client connecting to an internet-facing mail server on port 25, 465, or 587.
Exim is the most widely deployed mail transfer agent on the internet, running on a large share of Linux-based mail servers globally, with particularly deep penetration on Debian and Ubuntu systems. An unauthenticated RCE on an Exim server means full control over the machine: access to all email in transit, credentials stored locally, and a foothold into the wider internal network.
Mail servers are rarely isolated. They typically sit at the edge of your infrastructure, connected to internal directory services, ticketing systems, and often cloud-based productivity tools. Compromising an Exim server is rarely the end goal. It is usually the entry point. Mapping your attack surface should include every internet-facing service running vulnerable Exim builds.
No exploitation in the wild has been confirmed at the time of writing. That window will close. CVSS 9.8 unauthenticated RCEs on mail servers attract automated exploitation infrastructure within days of public disclosure.
You are affected if you run Exim versions 4.97 through 4.99.2 compiled with GnuTLS. This is the default on Debian stable and Ubuntu LTS distributions. Red Hat and SUSE systems use OpenSSL-linked Exim builds and are not affected by this specific vulnerability.
To check your build, run exim -bV | grep -i tls. If the output shows GnuTLS and your version falls in the affected range, patch immediately. The CHUNKING extension is enabled by default in modern Exim builds, meaning the attack vector is active without any unusual configuration.
Upgrade to Exim 4.99.3 immediately. This version, released 12 May 2026, contains the fix. Alternatively, apply your distribution's security update: Debian stable 4.98.2-1+deb13u2, Ubuntu 24.04 LTS via the coordinated security update. Verify the running binary is patched, not just the package version string.
If you cannot patch immediately, disable CHUNKING as a temporary mitigation. Add chunking_advertise_hosts = (empty value) to your Exim configuration to stop advertising the BDAT capability. This prevents the exploit trigger while you schedule the upgrade. Note: this is a mitigation, not a fix.
Review your Exim server's network exposure. Port 25 needs to be reachable for inbound mail, but ports 465 and 587 (submission) should be restricted to authenticated clients only. If your Exim server is accessible more broadly than necessary, tighten the firewall rules now.
Monitor for exploitation attempts. Look for anomalous SMTP sessions in your mail logs, particularly connections that send a BDAT command followed by an unusual TLS handshake sequence. Check your indicators of compromise against known Exim exploitation patterns.
Run exim -bV on the server. Look for a line containing TLS support information. GnuTLS-linked builds will show GnuTLS in the output. OpenSSL-linked builds are not affected. If the output shows OpenSSL, you do not need to take action for this specific vulnerability.
No confirmed exploitation has been reported as of 13 May 2026. However, the combination of a CVSS 9.8 score, unauthenticated access, and the scale of Exim deployment makes this a high-priority target for automated exploitation tools. The absence of confirmed exploitation today does not mean safe tomorrow.
Disabling CHUNKING prevents the specific exploit trigger described in CVE-2026-45185 and is a valid short-term mitigation. It does not address the underlying memory management flaw. Upgrading to 4.99.3 is the only complete fix. Treat the CHUNKING disable as a bridge, not a destination.
Exim has a history of critical flaws, including CVE-2019-10149 (remote command execution) and the Ghost vulnerability. What distinguishes CVE-2026-45185 is that it requires no prior authentication and no special server configuration to trigger, making it simpler to weaponise than several of its predecessors. Patch timelines from the Exim community suggest this vulnerability was addressed quickly once reported.
