Critical Heap Corruption in Exim (CVE-2026-45185): Why GnuTLS-Builds Must Upgrade Immediately
If you manage email infrastructure on Unix-like systems, Exim is likely a cornerstone of your Mail Transfer Agent (MTA) stack. Designed for robust email routing, queuing, and delivery, it powers countless mail servers worldwide. However, a newly disclosed vulnerability tracked as CVE-2026-45185 (internally dubbed Dead.Letter) introduces a severe use-after-free condition that can trigger heap corruption and, under the right conditions, remote code execution.
Unpacking CVE-2026-45185: The “Dead.Letter” Flaw
At its core, this vulnerability lives in Exim’s handling of binary data transmission (BDAT) when the server is compiled with GnuTLS. The issue manifests as a use-after-free bug during the parsing of a message body over a TLS-encrypted connection. According to Exim’s official advisory, the exploit chain begins when a client sends a TLS close_notify alert before the message body transfer completes, then immediately follows up with a final byte transmitted in cleartext over the same TCP connection.
During the TLS session teardown, Exim safely frees its internal TLS transfer buffer. However, a nested BDAT receive wrapper can still process incoming bytes and inadvertently call ungetc(). As Federico Kirschbaum, Head of Security Lab at XBOW, explained in a deep-dive analysis, this single-character write (\n) lands directly into the freed memory region. That one-byte overwrite corrupts Exim’s allocator metadata, effectively twisting the heap’s internal shape and handing an attacker the primitives needed to escalate to code execution.
Attack Prerequisites & System Impact
What makes this vulnerability particularly dangerous is how little configuration is required to trigger it. XBOW has described it as “one of the highest-caliber bugs” discovered in Exim to date, and the assessment holds up under technical scrutiny. To exploit the flaw, an attacker only needs two things:
- A valid TLS connection to the Exim server
- The ability to utilize the CHUNKING (
BDAT) SMTP extension
When those conditions are met, the race between TLS teardown and BDAT parsing opens a window for heap corruption. The impact range is broad: all Exim versions from 4.97 up to and including 4.99.2 are vulnerable. Crucially, the flaw only affects builds compiled with USE_GNUTLS=yes. Environments relying on OpenSSL or other TLS backends remain unaffected, which is an important distinction for administrators auditing their mail stack.
How the Patch Works and Why Mitigations Fall Short
Exim has addressed the issue in version 4.99.3, and the engineering team’s approach focuses on state hygiene rather than workarounds. The patch ensures that the input processing stack is cleanly reset the moment a TLS close_notify is received during an active BDAT transfer. By explicitly invalidating stale pointers and halting nested BDAT wrappers during session teardown, the fix eliminates the window where ungetc() could write into freed memory.
Unfortunately, there are no temporary mitigations or configuration toggles that resolve this issue. Because the vulnerability lives in the core memory management logic of the TLS/BDAT handshake, any delay in patching leaves the infrastructure exposed. All administrators should treat this as a critical, out-of-band upgrade.
Immediate Action Required
If your mail servers run Exim 4.97 through 4.99.2 with GnuTLS enabled, you should plan an upgrade to 4.99.3 immediately. Before applying the patch, verify your build flags to confirm whether USE_GNUTLS=yes is active. If you’re on OpenSSL, your exposure surface does not include this specific vulnerability, though routine patching remains best practice.
For full technical details, trigger conditions, and verification steps, refer to Exim’s official security advisory here and XBOW’s comprehensive exploit breakdown here. In the world of mail infrastructure, even a single byte written to the wrong memory address can unravel an entire server. Patch early, verify your TLS backends, and keep your MTA stack hardened.