Critical Exim Flaw Allows Remote Attackers To Execute Code On Vulnerable Mail Servers

A critical Exim vulnerability can allow unauthenticated remote attackers to execute arbitrary code on vulnerable mail servers.

The flaw, tracked as CVE-2026-45185 and nicknamed Dead.Letter, affects Exim 4.97 through 4.99.2 when the mail server uses the GnuTLS backend. Exim 4.99.3 fixes the issue.

Administrators should patch affected servers immediately because the Exim maintainers say there is no known mitigation other than upgrading. Systems built with OpenSSL or other TLS libraries are not affected by this specific vulnerability.

What is the Exim Dead.Letter vulnerability?

Dead.Letter is a remote use-after-free vulnerability in Exim’s BDAT message body parsing path. BDAT is part of the SMTP CHUNKING extension, which lets mail clients send message data in chunks.

The issue appears when Exim handles a TLS connection through GnuTLS. A remote attacker can start a TLS session, begin a CHUNKING transfer, send a TLS close notification before the message body finishes, and then send a final cleartext byte on the same TCP connection.

That sequence can make Exim write into a memory buffer that it already freed during TLS shutdown. The result is heap corruption, which can lead to arbitrary code execution.

Item	Details
Vulnerability name	Dead.Letter
CVE ID	CVE-2026-45185
Product	Exim mail server
Vulnerability type	Remote use-after-free
Affected area	BDAT message body parsing over GnuTLS
Severity	Critical, CVSS 9.8
Fixed version	Exim 4.99.3

Which Exim versions are affected?

The Exim advisory says the vulnerability affects all Exim versions from 4.97 up to and including 4.99.2. However, the bug only affects builds that use GnuTLS.

This distinction matters because not every Exim deployment uses the same TLS library. Servers built with OpenSSL or another TLS backend are outside the scope of this specific attack path.

The exposed configuration also needs STARTTLS and CHUNKING to be advertised. Many internet-facing mail servers use these features, so administrators should verify their own build and service configuration rather than assume they are safe.

Deployment	Status
Exim 4.97 through 4.99.2 with GnuTLS	Affected
Exim 4.99.3	Fixed
Exim builds using OpenSSL	Not affected by this specific flaw
Exim builds using other non-GnuTLS TLS libraries	Not affected by this specific flaw
Servers without public SMTP exposure	Lower exposure, but still should be checked and patched if affected

Why CVE-2026-45185 is dangerous

The vulnerability is dangerous because attackers do not need valid credentials. They only need network access to a vulnerable Exim service that accepts the required SMTP and TLS sequence.

Successful exploitation could let an attacker run code in the context of the Exim process. On many mail servers, that can create serious risk because mail transfer agents often handle sensitive mail queues, local delivery paths, and system-level operations.

XBOW, which discovered the flaw, said the memory corruption begins with a single-byte write into freed memory. That may sound small, but the researchers said it can give attackers enough control to build a working exploit path.

How the attack works

The attack path depends on the interaction between Exim’s SMTP state machine, the BDAT transfer path, and GnuTLS shutdown behavior.

During a normal TLS shutdown, Exim can free its internal transfer buffer. The bug appears because a nested BDAT receive wrapper can still process incoming data after that buffer has been freed.

When the attacker sends a final cleartext byte after the TLS close notification, Exim can write into the freed memory region. That stale memory write corrupts heap data and can lead to remote code execution.

• The attacker connects to the Exim SMTP service.
• The attacker starts a TLS session through STARTTLS.
• The attacker uses the CHUNKING extension and begins a BDAT transfer.
• The attacker sends a TLS close notification before the body transfer completes.
• The attacker sends one final cleartext byte on the same TCP connection.
• Exim can write into freed memory, causing heap corruption.

Who discovered the vulnerability?

Federico Kirschbaum, head of Security Lab at XBOW, discovered and reported CVE-2026-45185 to the Exim maintainers on May 1, 2026.

The Exim maintainers acknowledged the report on May 5 and began preparing a private fix. Distributors received notice before the public release so they could prepare coordinated packages.

Exim published the public advisory and released version 4.99.3 on May 12, 2026.

Date	Event
May 1, 2026	XBOW reported the vulnerability to Exim.
May 5, 2026	Exim maintainers acknowledged the report and confirmed a fix was being prepared.
May 7, 2026	Exim maintainers began coordinated release planning.
May 10, 2026	Distributors received restricted access to fixes.
May 12, 2026	Exim released 4.99.3 and published the advisory.

Patch status and mitigation guidance

Exim 4.99.3 is the official upstream fix for CVE-2026-45185. The Exim project says all affected users should upgrade as soon as possible.

The advisory also states that there is no known mitigation other than upgrading. Disabling useful mail features can break service, and disabling TLS would create a weaker security posture for normal mail traffic.

Organizations that use distribution packages should apply vendor security updates from their Linux distribution and restart Exim. They should also verify that the running Exim binary uses patched code after the update.

How administrators can check exposure

Administrators should first identify every internet-facing Exim instance. Mail servers often remain exposed for years, especially in hosting environments, legacy applications, and older relay systems.

Next, teams should check the Exim version and confirm whether the binary uses GnuTLS. A version number alone is not enough because the vulnerability depends on the TLS backend.

Servers that advertise STARTTLS and CHUNKING should receive priority review, especially when they accept connections on public SMTP ports.

1. Identify all Exim servers in production, staging, and legacy environments.
2. Check whether each system runs Exim 4.97 through 4.99.2.
3. Confirm whether the Exim build uses GnuTLS.
4. Check whether STARTTLS and CHUNKING appear in the SMTP EHLO response.
5. Apply Exim 4.99.3 or your distribution’s security package.
6. Restart Exim after patching.
7. Verify that the running service uses the patched binary.
8. Review logs for unusual TLS shutdowns, malformed BDAT transfers, or repeated failed SMTP sessions.

Why mail servers need urgent attention

Mail servers sit directly on the internet by design. They also often connect to internal routing, authentication, spam filtering, storage, and delivery systems.

A remote code execution flaw in this layer can become a high-value entry point for attackers. Even when the first compromise lands inside the mail server process, attackers may try to move toward credentials, mail spools, configuration files, and other internal systems.

That makes fast patching more important than waiting for broad exploitation reports. Administrators should treat Exim 4.99.3 or the matching distribution fix as an urgent update for any affected GnuTLS-backed deployment.

FAQ