Exim 'Dead.Letter' Flaw Enables Unauthenticated RCE on Mail Servers

A critical vulnerability in Exim mail servers could let remote attackers achieve code execution without authentication. Tracked as CVE-2026-45185 and nicknamed "Dead.Letter," the flaw affects all Exim versions from 4.97 through 4.99.2 when compiled with GnuTLS support.

Security researchers at XBOW discovered the bug and reported it to Exim maintainers on May 1. Federico Kirschbaum, who leads XBOW's Security Lab, described it as "one of the highest-caliber bugs" his team has found in the mail transfer agent.

How Dead.Letter Works

The vulnerability lives in Exim's BDAT message body parsing—the binary data transmission extension used in SMTP CHUNKING. Here's the attack sequence:

1. Attacker establishes a TLS connection to the Exim server
2. Begins a BDAT transfer but sends a TLS close_notify alert before completion
3. Follows immediately with a cleartext byte on the same TCP connection

When this happens, Exim frees its TLS transfer buffer during session teardown. But a nested BDAT receive wrapper still processes incoming bytes and calls ungetc(), which writes a newline character into the already-freed memory region.

That single byte write into freed heap memory is enough. Heap corruption opens the door to arbitrary code execution.

Affected Systems

The scope is narrower than it first appears. Only Exim builds compiled with USE_GNUTLS=yes are vulnerable. Servers using OpenSSL for TLS remain unaffected.

That said, many Linux distributions ship GnuTLS-enabled Exim packages by default. Debian, Ubuntu, and several others have pushed updates. Administrators should verify their build configuration:

exim -bV | grep -i tls

Look for "GnuTLS" in the output. If present, you're in scope.

Exploitation Requirements Are Minimal

Unlike many mail server vulnerabilities that require authentication or specific configurations, Dead.Letter needs almost nothing:

• Ability to establish a TLS connection to the server
• Server must support CHUNKING (BDAT) SMTP extension—which is enabled by default

No special server configuration. No valid credentials. An attacker just needs network access to port 25 (or wherever Exim listens).

Patch Immediately

Version 4.99.3 fixes the vulnerability. No workaround exists. If you can't upgrade immediately, consider temporarily restricting SMTP access to trusted sources—though that's rarely practical for production mail infrastructure.

Given the criticality, this vulnerability will likely be added to CISA's Known Exploited Vulnerabilities catalog if exploitation is observed. We've seen similar critical mail server flaws weaponized within days of disclosure.

Why This Matters

Exim is the most widely deployed mail transfer agent on the internet, handling an estimated 60% of publicly visible mail servers according to historical surveys. A pre-auth RCE in such pervasive infrastructure is a tier-one concern.

Mail servers typically hold sensitive data: credentials, confidential communications, and often domain-wide access through password reset mechanisms. Compromising the MTA frequently means compromising everything downstream—understanding the full impact of such incidents is covered in our data breach explainer.

XBOW's detailed technical writeup walks through the exploitation mechanics for those wanting the full analysis. For defenders, the message is simpler: check your Exim version, verify your TLS library, and upgrade to 4.99.3 today.

Organizations managing critical infrastructure should review our vulnerability news coverage for ongoing updates as the situation develops.