Exim Mail Server RCE Requires Zero Auth—Patch to 4.99.3 Now

A critical use-after-free vulnerability in Exim allows unauthenticated remote code execution against mail servers running default configurations. Tracked as CVE-2026-45185 and dubbed "Dead.Letter," the flaw affects Exim versions 4.97 through 4.99.2 when compiled with GnuTLS—the default TLS library on most Linux distributions.

The barrier to exploitation is essentially zero: no authentication, no non-standard configuration, just a TLS connection with BDAT support (enabled by default in modern Exim).

Technical Details

The vulnerability lives in Exim's TLS shutdown handling during BDAT (chunked SMTP) traffic processing. Here's what happens:

1. Exim allocates a TLS transfer buffer for handling encrypted data
2. During TLS shutdown, Exim frees that buffer
3. The code continues using stale callback references that can write data into the freed memory region
4. Attacker-controlled data lands in freed memory, achieving code execution

XBOW researcher Federico Kirschbaum discovered the flaw and reported it to Exim maintainers on May 1, 2026. The patch landed in version 4.99.3, released May 12.

Who's Vulnerable

Affected configurations:

• Exim 4.97 through 4.99.2
• Compiled with GnuTLS (default on Debian, Ubuntu, many others)
• STARTTLS and CHUNKING (BDAT) advertised

Not affected:

• Exim compiled with OpenSSL instead of GnuTLS
• Exim versions before 4.97
• Servers that have disabled BDAT/CHUNKING support

The catch is that most production Exim installations meet all the vulnerable criteria. GnuTLS is the default on Debian-based systems, and BDAT support has been enabled by default since Exim 4.88.

Scale of Exposure

Exim handles an estimated 57% of the world's email servers according to E-Soft surveys. Even a fraction of vulnerable instances represents millions of servers.

Previous Exim vulnerabilities have drawn immediate attention from threat actors. The 2019 Exim CVE-2019-15846 was weaponized within days of disclosure, with attackers scanning for vulnerable servers en masse.

Remediation Steps

1. Upgrade to Exim 4.99.3 — The patched version is available from the official Exim site
2. Rebuild with OpenSSL — If upgrading isn't immediately possible, recompiling Exim with OpenSSL instead of GnuTLS removes the vulnerable code path
3. Disable CHUNKING — Adding chunking_advertise_hosts = (empty value) to your Exim configuration disables BDAT support, though this may impact mail delivery from some senders

Exploitation Timeline

Given the combination of factors—unauthenticated access, default configuration vulnerability, and massive deployment footprint—expect active exploitation to follow quickly if it hasn't already begun.

The 11-day window between report and patch is tight by coordinated disclosure standards, but the simplicity of exploitation means motivated attackers likely reverse-engineered the fix within hours of the 4.99.3 release.

This follows a pattern we've seen with other critical mail server vulnerabilities, where threat actors prioritize email infrastructure for its access to sensitive communications and its value as a pivot point into enterprise networks.

Organizations running Exim should also review basic online safety practices for mail server hardening—network segmentation, monitoring for anomalous connections, and having incident response plans ready.