Exim, the Unix mail transfer agent found on countless production servers, has disclosed a memory corruption vulnerability that deserves immediate attention from infrastructure operators. CVE-2026-45185, nicknamed Dead.Letter, affects how Exim processes BDAT (Binary Data) commands under specific TLS configurations—a seemingly narrow surface that can have serious consequences if your deployment matches the vulnerable profile.
The BDAT Command and Use-After-Free Mechanics
BDAT is part of the SMTP protocol extension that allows clients to send binary message data without needing base64 encoding. Exim implements this feature to optimise mail ingestion from other MTAs and from SMTP clients that support it. The vulnerability lies in how Exim manages memory during BDAT processing when using GnuTLS for TLS termination.
A use-after-free occurs when code attempts to access memory that has already been freed. In this case, the flaw allows an attacker to craft a malformed BDAT sequence that causes Exim to reference memory regions that have been deallocated. If an attacker controls the timing and content of BDAT frames, they may trigger memory corruption that leads to code execution within the mail process context.
The critical detail: this affects only Exim builds compiled against GnuTLS. Exim compiled with OpenSSL does not share the same code path, which is why the vulnerability scope is narrower—but still significant for operators who chose GnuTLS for policy or compliance reasons.
Who Is At Risk
Your Exim installation is vulnerable if all of the following apply:
- You run Exim as an SMTP server (inbound or relay mail handling).
- Your Exim binary was built with GnuTLS support.
- The BDAT command is not explicitly disabled in your configuration.
- You accept SMTP connections from untrusted networks or the internet.
Isolated internal relays or mail gateways that only receive connections from authenticated, trusted sources face lower risk. However, any public-facing SMTP endpoint is a target.
Patching and Mitigation Options
Exim has released patched versions that correct the memory handling in the BDAT handler. The recommended action is to upgrade to a version that includes the fix. Check your distribution's package repositories first—many Linux distributions will backport the security patch into their stable release branches rather than forcing a major version jump.
If immediate patching is not feasible, two interim mitigations are available:
- Disable BDAT support in your Exim configuration by setting
pipelining_advertise_hoststo exclude remote servers, or by explicitly removing BDAT from the capabilities list in your SMTP ACLs. - Restrict SMTP access to known upstream relays and trusted networks only, reducing the attack surface to authenticated or pre-vetted connections.
Neither mitigation is a substitute for patching; they buy time whilst you plan upgrades.
Testing and Deployment Strategy
When rolling out the patched Exim version, test it first in a staging environment with your real mail volume and TLS configuration. Verify that BDAT handling works correctly and that mail throughput is not affected. Pay particular attention to connections from downstream MTAs or mail clients that rely on BDAT for efficiency.
Monitor logs for any SMTP connection failures or TLS negotiation issues immediately after deployment. A use-after-free exploit attempt may leave artifacts in syslog or Exim's main log, though a successful silent corruption is also possible.
For mail hosting operators and datacenter teams, this is a reminder to maintain a patch cadence for core infrastructure components. Exim is often overlooked in favour of more visible services, but a compromised mail relay can become a beachhead for lateral movement into your network or a launching point for outbound spam and phishing campaigns.
The scope of CVE-2026-45185 may be narrower than a blanket Exim vulnerability, but the consequences of exploitation—memory corruption leading to code execution—demand a swift and methodical response. Prioritise patching your public-facing or relay mail servers, and verify your GnuTLS build status before deprioritising this update.
