Exim CVE-2026-45185: Dead.Letter pre-auth RCE

In May 2026, XBOW security researcher Federico Kirschbaum disclosed a critical vulnerability in the Exim mail transfer agent. CVE-2026-45185, nicknamed Dead.Letter, is a use-after-free bug that lets an unauthenticated attacker run code on your mail server — no account, no token, no interaction from any of your users. The CVSS score is 9.8 (Critical).

The vulnerability is fixed in Exim 4.99.3. If you run Exim and have not checked your installation since May, read through this before you do anything else.

Who is affected

CVE-2026-45185 affects Exim versions 4.97 through 4.99.2 — but only builds compiled against the GnuTLS TLS library, on servers where both STARTTLS and the CHUNKING extension are advertised. Three months after disclosure, a meaningful number of mail servers on the internet remain on vulnerable versions.

OpenSSL builds are not affected. The bug is specific to how GnuTLS handles TLS session teardown. If your Exim was compiled against OpenSSL, you are not exposed to this particular vulnerability.

Debian, Ubuntu, and most Debian-derived distributions ship Exim linked against GnuTLS by default. cPanel and Plesk installations that include Exim typically also ship the GnuTLS build. If you run Exim on Debian or a derivative and have not explicitly rebuilt it against OpenSSL, your build is GnuTLS.

The bug: a single byte written to freed memory

The CHUNKING extension — defined in RFC 3030 — lets a sending mail server transmit a message body in multiple chunks using the BDAT command rather than the classic DATA command. Exim enables CHUNKING by default when compiled with CHUNKING support, which is the case in standard Debian packages.

Here is what happens when the bug triggers:

1. An attacker opens an SMTP connection, upgrades it to TLS via STARTTLS, and begins a BDAT chunked transmission.
2. Before the transfer completes, the attacker sends a TLS close_notify alert, signalling shutdown.
3. Exim's TLS cleanup path frees xfer_buffer, the internal transfer buffer.
4. The nested BDAT receive wrapper still holds a stale pointer into that buffer. It calls bdat_ungetc() → tls_ungetc(), which writes a single \n byte into the freed memory region.
5. That one-byte write corrupts heap allocator metadata.
6. On the next allocation, the corrupted metadata enables controlled memory corruption.

From there, XBOW demonstrated multiple exploitation paths to code execution: heap-based FILE struct hijacking on systems without PIE, ACL pointer corruption via storeblock inflation on systems with ASLR but without PIE, and confirmed stack address leak primitives for fully hardened targets. In the most common real-world configuration — Debian's Exim package on a standard VPS — reliable exploitation is within reach of a motivated attacker.

XBOW's own assessment: "Triggering this bug requires almost no special configuration on the server. That, more than the technical shape of the corruption itself, is what makes it one of the highest-caliber bugs discovered in Exim to date."

Check your server in two minutes

You need three things to be true for this vulnerability to apply: an Exim version in the 4.97–4.99.2 range, a GnuTLS build, and CHUNKING advertised. Check all three at once:

Run exim -bV on your mail server. The output shows the version number and the compile-time options. You are looking for:

• Version: anything between 4.97 and 4.99.2 is affected.
• TLS library: look for the string GnuTLS in the build options. If you see OpenSSL instead, you are not affected by this CVE.
• CHUNKING: look for CHUNKING in the list of built-in features. If it appears, the extension is compiled in.

To confirm CHUNKING is actually advertised to remote senders, run this against your own server:

openssl s_client -connect yourdomain.com:25 -starttls smtp

After the STARTTLS handshake, issue EHLO yourdomain.com. If CHUNKING appears in the list of advertised extensions, the attack surface is live.

If you prefer an automated check, a detection script is available at github.com/liamromanis101/Dead.Letter-CVE-2026-45185. It checks version, TLS library, whether CHUNKING is configured, and system-level mitigations such as ASLR level and glibc version, and exits with code 0 (safe), 1 (vulnerable), or 2 (inconclusive).

What to do

Upgrade to Exim 4.99.3. This is the only real fix. The patch corrects the memory lifecycle issue in the TLS shutdown path. On Debian and Ubuntu, the security teams have backported the fix — run apt-get update && apt-get upgrade exim4 and confirm the installed version with dpkg -l exim4.

If you cannot patch immediately — for instance, a hosting environment where the package is managed by a control panel — disable CHUNKING as a temporary measure. Add this line to your Exim main configuration (typically /etc/exim4/exim4.conf.template or /etc/exim.conf):

chunking_advertise_hosts =

Setting this to an empty value prevents Exim from advertising CHUNKING to any remote sender. Mail delivery continues normally; senders that prefer CHUNKING fall back to standard DATA. Restart Exim, then verify that CHUNKING no longer appears in your server's EHLO response using the openssl s_client command above.

This is a mitigation, not a fix. The underlying UAF still exists in the code. Patch as soon as you can.

Why unpatched Exim servers matter beyond the immediate host

A mail server is not a peripheral service. It has access to every message in transit. It typically runs as a privileged process on the host. It is reachable from the internet on port 25 by design, because that is the protocol.

Code execution on the mail server process means access to mail queue contents, the ability to copy or modify messages in transit, and a foothold on the host from which lateral movement can begin. For shared hosting environments where a single Exim process handles mail for dozens or hundreds of domains, the blast radius extends to every one of them.

Exim's widespread use — it is the default MTA on Debian and widely deployed through control panels — means the affected population is large. Three months after disclosure is long enough for a capable attacker to have built and deployed a working exploit. If you have not checked your installation, now is a reasonable time.

What ClickScan checks

ClickScan scans your domain's external exposure, including SMTP service banners, advertised extensions, STARTTLS support, and TLS certificate health. If your mail server is running an identifiable Exim version with CHUNKING in its EHLO banner, the scan will surface that alongside your HTTP security headers, email authentication records, and certificate validity. See what ClickScan checks.

Sources: XBOW — Dead.Letter research post and EXIM-Security-2026-05-01.1 advisory (May 12, 2026); BleepingComputer; The Hacker News. No in-the-wild exploitation had been publicly confirmed at the time of the May disclosure; treat the risk as researcher-assessed exploitation with a low trigger barrier, not a confirmed active campaign.