CVE-2026-45185 (a critical use-after-free vulnerability in Exim — the world’s most widely deployed Mail Transfer Agent — affecting all GnuTLS-compiled builds running versions 4.97 through 4.99.2) allows an unauthenticated remote attacker to execute arbitrary code on any publicly reachable Exim server through a single manipulated SMTP session. Tracked under the name “Dead.Letter” and carrying a CVSS v3.1 score of 9.8 (Critical — remotely exploitable with no authentication or user interaction required), the flaw was patched in Exim 4.99.3, released May 12, 2026. The subsequent 4.99.4 release additionally addresses a companion information-disclosure flaw and is the recommended upgrade target.
// 01 CVE-2026-45185: Technical Details
CVE-2026-45185 is formally classified as CWE-416: Use-After-Free — a class of memory safety bug where a freed heap region is accessed again through a dangling pointer, allowing an attacker to corrupt allocator metadata and ultimately gain control of program execution. The flaw lives in Exim’s implementation of the BDAT command, part of the CHUNKING extension to SMTP defined in RFC 3030. CHUNKING allows mail clients to send message bodies in binary chunks, eliminating the overhead of the legacy dot-stuffing encoding required by the traditional DATA command. Both STARTTLS and CHUNKING are advertised by default in modern Exim builds.
The bug surfaces at the intersection of two subsystems: Exim’s CHUNKING body receiver and GnuTLS’s TLS session teardown logic. During a BDAT body transfer over a STARTTLS-encrypted connection, if a mail client sends a TLS close_notify alert — the standard signal to cleanly shut down the encrypted session — before the declared message body transfer is complete, Exim’s GnuTLS layer begins tearing down the TLS session and frees the internal TLS transfer buffer. However, Exim’s lower-level receive pointers are not cleared during this teardown.
If the attacker then sends a single cleartext byte on the same underlying TCP connection, the BDAT receive wrapper’s nested ungetc() call writes that byte into the already-freed buffer region, corrupting heap allocator metadata. XBOW researcher Federico Kirschbaum, who discovered and reported the flaw, demonstrated that the heap layout of a standard Exim installation is predictable enough to chain the initial corruption into a full code execution primitive with high reliability across affected builds.
// 02 Exploitation Status and Threat Landscape
As of May 30, 2026, there is no publicly available PoC (Proof-of-Concept — working exploit code published openly) for CVE-2026-45185, and CISA has not yet added it to its Known Exploited Vulnerabilities (KEV) catalog (a list maintained by the U.S. Cybersecurity and Infrastructure Security Agency that confirms real-world active exploitation). No threat actor has been publicly attributed to exploitation activity targeting this specific flaw.
The absence of public PoC code does not translate to low risk. Kirschbaum’s disclosure noted that the barrier to triggering CVE-2026-45185 is “extremely low”: no account on the target server is needed, no non-default configuration is required (STARTTLS and CHUNKING are on by default), and the attack needs nothing more than a standard SMTP client capable of sending mid-session TLS control signals. The only constraint is that the target must be running a GnuTLS-compiled Exim build — but that is precisely the default on Debian and Ubuntu.
Prior Exim vulnerabilities with comparable severity profiles have consistently triggered mass scanning campaigns within days of public disclosure. CVE-2019-10149 (“The Return of the WIZard”), which allowed unauthenticated command injection in Exim’s address-handling code, was weaponized by automated worm campaigns within 24 hours of the patch release and ultimately compromised roughly 3.5 million servers. The 2021 21Nails advisory disclosed 21 simultaneous Exim vulnerabilities — several of them pre-authentication RCEs — and again triggered rapid mass exploitation. Security teams should plan accordingly.
// 03 Who Is Affected
CVE-2026-45185 exclusively affects Exim builds compiled against the GnuTLS library (USE_GNUTLS=yes). Builds using OpenSSL are not vulnerable — the stale-pointer condition occurs only in GnuTLS’s TLS teardown path and does not exist in OpenSSL’s equivalent.
In practice, GnuTLS is the default TLS library for Exim on Debian and all Debian-derived distributions: Ubuntu, Kali Linux, Linux Mint, Pop!_OS, and others. Red Hat Enterprise Linux, CentOS, Rocky Linux, AlmaLinux, and Fedora ship OpenSSL-based Exim packages and are therefore not affected by this specific vulnerability.
- Affected version range: Exim 4.97 through 4.99.2, GnuTLS builds only
- Not affected: Exim 4.99.3 and later; all OpenSSL-compiled builds; Exim versions prior to 4.97
Exim is the most widely deployed Mail Transfer Agent (MTA) on the internet, powering an estimated 57% of all publicly reachable mail servers. The GnuTLS subset — concentrated on Debian and Ubuntu systems — represents hundreds of thousands of exposed SMTP endpoints. Shodan and Censys port-25 banner scans already showed a significant proportion of servers still running version strings in the 4.97–4.99.2 range in the days following the May 22 public disclosure. Historical Exim disclosures have shown that a large proportion of servers remain unpatched weeks after patches become available.
// 04 What You Should Do Right Now
- Check your Exim version and TLS library. Run
exim --versionon your mail server. Look for both the version number and the TLS library string in the output — if it showsGnuTLS, your build is in the affected class. - Upgrade to Exim 4.99.4 (which bundles the CVE-2026-45185 RCE fix from 4.99.3 and the CVE-2026-48840 information-disclosure fix in 4.99.4). On Debian/Ubuntu:
apt update && apt install --only-upgrade exim4
exim --version # confirm the new version string
Self-compiled builds: download the latest source from the official Exim mirror list and rebuild with your existing configuration flags.
- If you cannot patch immediately, disable the CHUNKING extension as a temporary workaround by adding the following line to
/etc/exim4/exim4.conf.template(or your mainexim4.conf), then restart Exim:
chunking_advertise_hosts =
This empties the list of hosts to which CHUNKING is advertised, preventing BDAT from being negotiated and eliminating the attack path. Note: this may marginally reduce throughput with senders that prefer CHUNKING, but it does not break mail delivery.
- Verify the workaround is active. After restarting Exim, connect to the SMTP port and check that
CHUNKINGno longer appears in the EHLO capabilities banner:
openssl s_client -connect localhost:25 -starttls smtp
# CHUNKING should be absent from the EHLO response
- Check for suspicious BDAT activity. Review
/var/log/exim4/mainlogfor BDAT transactions combined with mid-session TLS close events from external IP addresses. Aclose_notifyarriving before the declared byte count is complete — followed immediately by a connection reset — is consistent with exploitation or scanning activity targeting CVE-2026-45185. - Prioritize public-facing mail servers. Any Exim instance accepting inbound SMTP from the internet (port 25) is the primary attack surface. Internal relay servers with no external connectivity carry significantly lower risk and can be scheduled for the next maintenance window.
// 05 Background: Understanding the Risk
Exim occupies a unique position in internet infrastructure: it is the default MTA shipped and enabled in every standard Debian and Ubuntu installation. Unlike web servers — where administrators consciously choose between Apache, NGINX, or Caddy — organizations running Debian and Ubuntu frequently run Exim simply because it was pre-installed and “just worked.” This means a significant fraction of affected deployments belong to organizations with limited dedicated mail server expertise, precisely the population least likely to apply security patches within days of disclosure.
Use-after-free vulnerabilities in SMTP-handling code are particularly dangerous because SMTP servers are, by design, reachable from the entire internet without any prior authentication. There is no IP allowlist, no client certificate requirement, and no rate-limiting that an attacker cannot trivially circumvent. An attacker scanning port 25 for Exim banner strings matching the vulnerable version range can enumerate targets in minutes and attempt exploitation with zero prior knowledge of the target environment.
The BDAT/CHUNKING extension at the center of CVE-2026-45185 was introduced to improve performance by eliminating the encoding overhead of the legacy DATA command. It was designed as a pure efficiency improvement and enabled by default precisely because it is normally harmless. This is the persistent challenge with default-on features in security-sensitive network daemons: attackers can rely on the capability being present across virtually every unmodified installation without needing to fingerprint or probe for specific configurations.
The companion vulnerability disclosed in the same release cycle — CVE-2026-48840, CVSS 5.3 — is a separate, lower-severity information disclosure flaw in Exim’s PROXY protocol parser affecting versions 4.88 through 4.99.3 on builds where PROXY_PROTOCOL_HEADER_TIMEOUT is in use. It leaks uninitialized stack memory to a connected client in certain short-payload scenarios. While far less severe than CVE-2026-45185, it is also patched in the 4.99.4 release, making a direct upgrade to 4.99.4 the cleanest path for administrators who want to close both issues in a single operation.
// 06 Conclusion
CVE-2026-45185 “Dead.Letter” is a critical unauthenticated RCE affecting all GnuTLS-compiled Exim builds running versions 4.97 through 4.99.2 — the default configuration on Debian and Ubuntu. With no authentication required, no special server configuration needed, and a low technical barrier to exploitation, the primary question is not whether mass scanning will begin but when. System administrators running affected Exim versions should upgrade to 4.99.4 immediately; those unable to patch today should apply the CHUNKING workaround as an interim measure while scheduling the upgrade.