Dead.Letter is a Debian and Ubuntu problem, and the popular workaround is wrong

If you run Exim on Debian or Ubuntu and you read a tech blog over the weekend telling you to set chunking_advertise_hosts = and call it a day, you are still exploitable. The disclosure coverage is consistent that the 2017-era workaround does not close this bug. Patch the package, or accept that your perimeter mail server is reachable pre-auth from anyone who can speak STARTTLS.

That is the whole story for most operators. The rest of this post is the operational shape: who is actually affected, why one TLS library makes the difference between “patch tonight” and “ignore the news,” and what to verify before Thursday’s change window.

What shipped

CVE-2026-45185, nicknamed Dead.Letter by its finder, is a CVSS 9.8 pre-auth use-after-free in Exim’s SMTP CHUNKING (BDAT) receive path. It was disclosed on 2026-05-12 by Federico Kirschbaum of XBOW, and fixed in Exim 4.99.3 the same day, according to Bleeping Computer’s coverage. Debian and Ubuntu shipped packages on disclosure day.

The mechanism, as summarized by The Hacker News and CyCognito’s writeup: a client negotiates STARTTLS, sends a BDAT command to begin a chunked transfer, then sends a TLS close_notify alert mid-chunk. Exim’s GnuTLS code processes the alert and frees the receive buffer, but the BDAT wrapper sitting one layer above is still mid-chunk and still holds the function-pointer table. One cleartext byte after the teardown drives the BDAT loop into ungetc(), which writes a single '\n' into the freed region. One byte into allocator metadata is enough to pivot to RCE.

The OpenSSL-linked code path does not have this lifetime mismatch. Same Exim source tree, different TLS backend, different exposure.

Who is actually affected

This is unusual enough to say plainly: if you are on RHEL, AlmaLinux, Rocky, SUSE, or Fedora, you do not need to do anything for this CVE. Those distributions ship Exim linked against OpenSSL by default. The vulnerable code path is not in your binary. No RHSA or equivalent is expected, and that is not an oversight.

The affected pool is Debian, Ubuntu, and their derivatives. Debian has packaged exim4 against GnuTLS as the default TLS backend since at least the mid-2000s, a decision documented in Debian Bug #446036. Ubuntu inherits that choice. The affected version range upstream is Exim 4.97 through 4.99.2 inclusive, on builds compiled with USE_GNUTLS=yes.

Fixed packages were published on disclosure day:

• Debian via DSA-6265-1: 4.98.2-1+deb13u2 (trixie), 4.96-15+deb12u9 (bookworm), 4.94.2-7+deb11u5 (bullseye).
• Ubuntu via USN-8270-1: 4.99.1-1ubuntu1.2 (26.04), 4.98.2-1ubuntu2.2 (25.10), 4.97-4ubuntu4.5 (24.04 Noble), 4.95-4ubuntu2.8 (22.04 Jammy). 20.04 Focal was still listed as “needs evaluation” as of 2026-05-14; Focal is in ESM, so watch the USN feed if that is your fleet.

FreeBSD lets the operator pick the TLS backend at build time, and no VuXML entry had surfaced as of 2026-05-17. Do not infer safety from the absence of an advisory there. Check the binary.

Verify what you actually have

Two commands, run on the host:

exim -bV

Look for GnuTLS or OpenSSL in the TLS library line. That is the definitive answer.

ldd $(which exim) | grep -E 'gnutls|ssl'

Runtime confirmation in case someone in your past rebuilt the binary against a non-default backend.

Here is the same pair captured from a fresh debian:12 container and a fresh rockylinux:9 container. The Support for: line is the answer; the ldd output is the receipt.

And from any workstation that can reach the server, an EHLO probe to see whether CHUNKING is being advertised after STARTTLS:

openssl s_client -starttls smtp -connect mailserver.example.com:25

Then type EHLO test and look for 250-CHUNKING in the response. Upstream Exim defaults chunking_advertise_hosts to *, so anything self-compiled or running on a hosting panel like cPanel is almost certainly advertising it. Debian packaging has historically been more conservative on this default; the research on the 2026 packaging state is thin, so probe rather than assume.

The workaround that does not work

This is the part worth pinning to the change board. Several secondary sources have been recommending chunking_advertise_hosts = as a mitigation. That advice is a holdover from CVE-2017-16943, an earlier BDAT bug where setting the option to empty actually did remove the attack surface. It does not work here. The Bleeping Computer, Hacker News, and CyCognito writeups summarizing the disclosure are consistent that the GnuTLS teardown path is reachable independently of whether the server is advertising CHUNKING to the connecting client. The upstream EXIM-Security-2026-05-01.1 advisory and the oss-security disclosure thread are the primary documents, but the secondary coverage is what every operator report is leaning on this week.

The practical risk is not the bug. The practical risk is the sysadmin who reads the wrong post, edits one line in /etc/exim4/exim4.conf.localmacros, restarts the daemon, and goes back to the rest of the queue. That host is now both unpatched and labeled “mitigated” in someone’s spreadsheet, which is a worse outcome than knowing it is unpatched.

The one legitimate non-patch option is rebuilding Exim against OpenSSL. On Debian that means uncommenting OPENSSL:=1 in debian/rules and rebuilding the package. This is a real lift, defensible only if your package update is genuinely blocked. Disabling TLS entirely also removes the vulnerable path, and is worse than the bug.

The window

Patch this week. Not tonight necessarily, but not next sprint either.

There is no confirmed in-the-wild exploitation as of 2026-05-17, and CISA has not added the CVE to KEV. Five days post-disclosure, that absence is not informative. What is informative is Exim’s history: CVE-2019-10149 was being exploited within days, and the NSA later attributed sustained mass exploitation of unpatched Exim to Sandworm starting in August 2019. The 21Nails disclosure in 2021 had Qualys estimating roughly 60% of internet-connected mail servers exposed. The pattern is consistent enough that “no public PoC yet” is not a planning input.

The deployment is small. apt-get update && apt-get install --only-upgrade exim4-base exim4-daemon-light (or -heavy), then exim -bV to confirm the version moved. A daemon restart and a queue check. For most teams this is a 15-minute change inside an existing weekly window, not an emergency CAB.

If your Exim instance is not actually an inbound MX, the cheapest mitigation is the one you should already have: port 25 inbound blocked at the perimeter for hosts that have no business receiving outside mail. That is not a patch, but it removes exposure for submission relays and internal smart hosts while the package change waits its turn.

We send a short daily email when something like this lands, so mail-server operators do not read about it for the first time on a blog still recommending the 2017 fix.

The thing to walk away with is the split. RHEL family: nothing to do. Debian and Ubuntu: patch this week, and do not let anyone on your team paste in the 2017 workaround thinking it covers them. Bug-class familiarity is useful right up until the moment it is wrong.

Sources

• CVE-2026-45185 — NVD/NIST — 2026-05
• New critical Exim mailer flaw allows remote code execution — Bleeping Computer — 2026-05-12
• New Exim BDAT Vulnerability Exposes GnuTLS Builds — The Hacker News — 2026-05-12
• Emerging Threat: CVE-2026-45185 — CyCognito Blog — 2026-05
• Debian Bug #446036 — compile exim4 against OpenSSL instead of GnuTLS — 2007
• Debian Security Tracker: CVE-2026-45185 — 2026-05
• USN-8270-1: Exim vulnerability — Ubuntu Security — 2026-05-12
• EXIM-Security-2026-05-01.1 Advisory — 2026-05-12
• oss-security: [EXIM-Security-2026-05-01.1] Security Release 4.99.3 — 2026-05-12
• The Return of the WIZard: RCE in Exim (CVE-2019-10149) — Qualys advisory — 2019-06-05
• NSA: Sandworm Actors Exploiting Vulnerability in Exim Mail Transfer Agent — 2020-05-28
• 21Nails: Multiple Critical Vulnerabilities in Exim Mail Server — Qualys Blog — 2021-05-04