Critical Exim flaw enables remote code execution on GnuTLS builds

Threat summary

On May 12, 2026, Exim released version 4.99.3 to address a vulnerability, dubbed “Dead.Letter”, that can lead to unauthenticated remote code execution.

The vulnerability affects Exim versions 4.97 through 4.99.2 when built with GNU Transport Layer Security (GnuTLS). Builds using OpenSSL or other TLS libraries are not affected. The fix was released following coordinated disclosure with Linux distributions.

Exim is an open-source Mail Transfer Agent (MTA) used to receive, route, and deliver email on Unix-like operating systems. It is the default MTA on many Debian-based distributions, including Ubuntu, and is commonly deployed as an internet-facing service.

The flaw, tracked as CVE-2026-45185, stems from how Exim handles Simple Mail Transfer Protocol (SMTP) messages sent using the Binary Data Transmission (BDAT) extension over TLS. When a TLS session handled by GnuTLS is terminated before a BDAT transfer completes, Exim can free an internal TLS buffer that remains in use, resulting in heap corruption.

The vulnerability is remotely reachable over SMTP and does not require authentication, valid recipients, or user interaction. Exploitation is possible on servers that advertise STARTTLS and the CHUNKING (BDAT) extension, both of which are standard and commonly enabled on internet-facing mail servers. The issue is specific to Exim builds using GnuTLS and cannot be mitigated through configuration changes, feature disabling, or protocol restrictions.

Exim maintainers received the initial report through responsible disclosure on May 1 and coordinated disclosure with distributors between May 7-10. The public advisory and corrected release were issued on May 12. A detailed technical write-up describing exploit development was also published the same day.

Analysis

Successful exploitation of this flaw provides remote code execution in a core email service that is often directly exposed to the internet and closely integrated with internal systems. This creates risk for service disruption, mail interception, credential access, and follow-on compromise, depending on the deployment context.

In prior incidents, Exim vulnerabilities were observed being actively exploited against internet-facing mail servers shortly after public disclosure. These cases show that Exim flaws with remote code execution potential tend to attract rapid adversary interest due to the software's widespread exposure and central role in email infrastructure.

The Exim advisory and oss-security advisory state that no effective workarounds exist. Exim 4.99.3 addresses the issue by resetting internal input handling when a TLS close notification occurs during an active BDAT transfer.

Where available, distribution-provided patched packages address the same flaw. Identifying Exim versions in use and confirming whether deployed packages are built with GnuTLS is key to assessing exposure, particularly for external-facing SMTP services.

This issue primarily affects Debian, Ubuntu, and Debian-based environments running Exim 4.97 through 4.99.2. OpenSSL-based Exim builds, which are common on Red Hat Enterprise Linux-family and SUSE systems, are not affected.

Distribution name alone is not sufficient to determine exposure. The deciding factor is whether Exim was built with USE_GNUTLS=yes, as the Exim advisory explicitly states that only GnuTLS builds are vulnerable. Administrators can confirm the TLS backend by reviewing Exim’s build information using the exim -bV command.

Stay on top of emerging threats like this.

Sign up to receive a weekly roundup of our security intelligence feed. You'll be the first to know of emerging attack vectors, threats, and vulnerabilities. 

Sign up