On May 12, 2026, the maintainers of the Exim open-source Mail Transfer Agent (MTA) issued an urgent security advisory addressing a critical Use-After-Free (UAF) vulnerability.
Tracked as CVE-2026-45185 and dubbed “Dead.Letter” by the discovering researchers at XBOW Security Lab, this flaw allows unauthenticated remote attackers to execute arbitrary code on vulnerable systems.
Given that Exim is the default MTA on numerous Unix-like operating systems including major distributions like Debian and Ubuntu and processes a massive percentage of the internet’s email traffic, this vulnerability represents a severe threat to global enterprise infrastructure.
Exim RCE Vulnerability
At its core, CVE-2026-45185 is a memory corruption issue triggered by an intricate interaction between Exim’s parsing of Binary Data Transmission (BDAT) commands and its handling of Transport Layer Security (TLS) connections via the GnuTLS backend.
To understand the exploit, it is essential to look at the SMTP CHUNKING extension defined in RFC 3030. Unlike the traditional DATA command, which relies on a period (.) on a line by itself to signal the end of an email body, BDAT allows a client to declare the exact size of the payload upfront (e.g., BDAT 1024).
When Exim receives a BDAT command, it dynamically alters its internal state machine. It temporarily suspends its standard transport layer receive functions and pushes a nested wrapper—specifically bdat_push_receive_functions() to read the exact number of bytes specified.
The vulnerability manifests when a malicious client intentionally disrupts this flow. An attacker initiates an SMTP session, successfully negotiates a TLS connection using STARTTLS, and begins a BDAT chunk transfer.
Before the transfer completes, the attacker prematurely sends a TLS close_notify alert, immediately followed by a final, unencrypted byte in cleartext over the same TCP connection.
When Exim receives the close_notify alert, its GnuTLS backend dutifully begins tearing down the secure session. During this teardown process, Exim frees its internal 4096-byte plaintext TLS transfer buffer (xfer_buffer), which was allocated via store_malloc().
However, because the BDAT transfer was technically incomplete, Exim’s nested BDAT receive wrapper is still actively trying to process incoming bytes.
When the final cleartext byte arrives on the wire, the asynchronous nature of the state machine causes the BDAT parser to call the ungetc() function. This function takes the single rogue byte (typically a newline character, \n) and writes it back into what it believes is the active buffer.
Because the buffer was already freed during the TLS teardown, this results in a classic Use-After-Free scenario. That single one-byte write lands directly on Exim’s underlying memory allocator metadata.
By corrupting the internal shape of the heap allocator, an attacker can leverage this primitive to hijack execution flow and ultimately achieve full Remote Code Execution (RCE).
Noted that while a one-byte write might seem deceptively weak, the deterministic nature of Exim’s memory management makes it highly weaponizable, classifying Dead.Letter as one of the highest-caliber bugs discovered in Exim to date.
The severity of CVE-2026-45185 cannot be overstated. Triggering this vulnerability requires almost no special configuration. The attacker does not need valid credentials, a valid sender address, or any user interaction.
The only prerequisites for exploitation are that the target server is internet-facing, advertises STARTTLS, and supports the CHUNKING (BDAT) extension. These features are standard and enabled by default on the vast majority of modern mail servers.
A successful exploit grants the attacker code execution with the privileges of the Exim daemon. From this vantage point, an adversary can:
- Intercept and Modify Mail: Silently read, copy, or alter sensitive corporate communications and password reset emails.
- Establish Persistence: Deploy backdoors or web shells to maintain access to the compromised server.
- Facilitate Lateral Movement: Use the trusted mail server as a pivot point to attack internal networks and restricted subnets.
- Launch Further Attacks: Utilize the server’s high reputation to distribute phishing campaigns, spam, or ransomware payloads without triggering external spam filters.
It is critical to note a specific operational constraint: This vulnerability exclusively impacts Exim builds compiled with the GnuTLS backend (USE_GNUTLS=yes). Builds utilizing OpenSSL or other cryptographic libraries handle session teardown differently and are not susceptible to this specific memory corruption path.
Path and Mitigation
The discovery and patching of the Dead.Letter vulnerability is a prime example of effective coordinated disclosure between independent researchers and open-source maintainers:
- 2026-05-01 17:29 UTC: Federico Kirschbaum of XBOW Security Submits the initial vulnerability report to the Exim security team.
- 2026-05-05 02:53 UTC: Exim maintainer Heiko Schlittermann acknowledges the report; private remediation efforts begin.
- 2026-05-07 22:00 UTC: Preliminary announcement sent to the Openwall distributions mailing list to prepare OS vendors.
- 2026-05-10 20:00 UTC: Restricted access to the final patch is provided to trusted Linux distributors for packaging.
- 2026-05-12 14:00 UTC: Exim 4.99.3 is publicly released alongside the official security advisory.
There are no known configuration workarounds to mitigate CVE-2026-45185. Disabling BDAT or CHUNKING is often impractical and can severely disrupt modern mail flow. The only definitive solution is to patch the software.
Administrators must immediately check their Exim version and TLS backend compilation. You can verify your specific configuration by executing the command exim -bV in the terminal. If the output indicates a version between 4.97 and 4.99.2 and confirms the use of GnuTLS, the system is highly vulnerable.
System administrators should immediately utilize their distribution’s package manager (e.g., apt-get update && apt-get upgrade exim4 for Debian/Ubuntu environments) to pull the latest security releases. If you compile Exim from the source, download version 4.99.3 directly from the official Exim repositories.
The newly released patch fundamentally resolves the issue by ensuring that the input processing stack is cleanly reset whenever a TLS close notification is received during an active BDAT transfer, nullifying the stale pointers before they can be exploited.
Given the public availability of the technical details and the historical precedent of Exim vulnerabilities being rapidly weaponized by threat actors, any delay in patching significantly increases the risk of a total system compromise.
FAQ
What versions of Exim are vulnerable to CVE-2026-45185?
All Exim installations running versions 4.97 through 4.99.2 that are compiled with GnuTLS are vulnerable.
Are Exim servers built with OpenSSL affected by this flaw?
No, builds utilizing OpenSSL or other alternative TLS libraries are completely unaffected by this specific vulnerability.
Is there a temporary mitigation I can apply without updating?
No, there are no effective configuration workarounds; upgrading to version 4.99.3 is the only recommended solution.
How do I check if my server uses the vulnerable GnuTLS backend?
Run the command exim -bV in your server terminal to view the build information and verify the active TLS library.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.