Critical Exim Mailer Flaw Enables Remote Code Execution Attacks

A newly disclosed vulnerability in the widely used Exim mail transfer agent exposes thousands of internet-facing mail servers to unauthenticated remote code execution, threatening core email infrastructure across Linux and Unix-like systems.

Tracked as CVE-2026-45185 and nicknamed “Dead.Letter,” the bug resides in Exim’s handling of TLS-encrypted SMTP traffic, and BDAT chunked message bodies when compiled with the GnuTLS library.

Exim Mailer Flaw

Exim is a popular open-source mail transfer agent (MTA) used by ISPs, enterprises, and Linux distributions to receive, route, and deliver email.

The flaw affects Exim versions 4.97 through 4.99.2 when built with GnuTLS and configured to advertise both STARTTLS and CHUNKING (BDAT) in SMTP capabilities. OpenSSL-based Exim builds are not impacted, which gives administrators one important mitigation path.

CVE-2026-45185 is a remotely exploitable use-after-free (UAF) vulnerability in Exim’s BDAT message body parsing logic when GnuTLS handles the TLS session.

An unauthenticated attacker can trigger memory corruption – and ultimately arbitrary code execution – by sending a crafted sequence of SMTP commands that mix TLS shutdown with BDAT chunk processing on the same connection.

The vulnerability hinges on how Exim wires TLS I/O into its generic input layer and how BDAT “wraps” that input with its own receive functions. When a client issues STARTTLS, Exim creates a GnuTLS session, allocates a 4 KB transfer buffer (often called xferbuffer), and hooks TLS-aware read functions (tls_getc, tls_ungetc, etc.) into its SMTP parsing pipeline.

All subsequent SMTP bytes, including message bodies, flow through this buffer while the TLS session is active.

BDAT (from RFC 3030 CHUNKING) introduces a second layer: when a BDAT chunk starts, Exim pushes the current receive callbacks down into a “lower” row (lwr_receive_*) and replaces the top row with BDAT-specific wrappers (bdat_getc, bdat_ungetc).

These BDAT wrappers do not perform I/O themselves; they delegate to the saved lower layer, which, during TLS, remains the TLS receive path backed by the same transfer buffer.

The core bug occurs when the client sends a TLS close_notify message in the middle of a BDAT body. During TLS shutdown, Exim frees the transfer buffer as part of tearing down the GnuTLS session, but fails to fully unwind the BDAT receive stack.

The top-level callbacks are reset to plaintext (smtp_getc), yet the BDAT layer still holds a stale pointer to the now-freed TLS buffer via lwr_receive_ungetc, which still points at tls_ungetc.

Later, while finishing BDAT parsing, Exim attempts to “push back” a byte using bdat_ungetc in a corner case where it repairs a missing CRLF sequence. Because BDAT still calls the lower layer’s ungetc, this ends up invoking tls_ungetc on the freed buffer, performing a single-byte write into heap memory that has already been returned to the allocator.

That lone newline byte lands on Exim’s internal allocator metadata (its “store” pool headers), allowing attackers to corrupt pool length fields and shape subsequent heap behavior in a controlled way.

From One Byte to Remote Code Execution

Although the primitive is “only” a one-byte write into freed memory, the surrounding allocator design makes it powerful. Exim uses a custom pool allocator (“store”) built on top of malloc, where each pool is a list of storeblock chunks with header fields like next and length that guide future allocations.

By carefully reclaiming the freed region with controlled allocations (for example, via DKIM verification paths that use storemalloc in specific pools), an attacker can position allocator metadata inside the freed buffer.

Flipping a single byte of the length field in a storeblock header allows an attacker to “inflate” the allocator’s view of available space, making Exim believe a pool spans far beyond the real end of the underlying malloc chunk.

Subsequently, attacker-controlled SMTP commands (such as long MAIL FROM or RCPT TO arguments) then cause Exim to write strings at attacker-chosen offsets into what it thinks is pool memory, but actually overlaps other sensitive structures.

XBOW’s write-up shows that this primitive can be used in multiple ways:

• In a CTF-style setup with no ASLR and non-PIE binaries, an LLM-guided exploit corrupted glibc largebin pointers inside the freed chunk, hijacked a future malloc(4096), overlapped a FILE structure, and pivoted into a ROP chain via FSOP to run arbitrary code.
• Against more realistic builds with ASLR enabled, a human-crafted exploit instead targeted Exim’s own store allocator, overwriting function pointers in global ACL hooks so that when Exim executed pre-DATA ACL logic, it effectively ran attacker-supplied shell commands.

In both cases, exploitation is fully unauthenticated. It requires no special Exim configuration beyond the vulnerable GnuTLS/BDAT combination being present.

Public advisories warn that successful exploitation can result in complete compromise of the mail server, including the ability to read or tamper with email, move laterally, or deploy additional malware.

An unusual aspect of CVE-2026-45185 is that the discoverer used the disclosure window to benchmark human exploit development against an autonomous large language model.

XBOW reports that a fully automated LLM produced working exploit chains in a controlled environment, relying heavily on well-known glibc heap exploitation patterns and FSOP primitives. In contrast, human-guided work produced more target-specific allocator attacks and cleaner heap layouts against production-like builds.

The experiment underscores that, even if LLMs struggle with full real-world exploitation end-to-end, they can already accelerate vulnerability triage, heap-shape reasoning, and proof-of-concept generation.

This, in turn, shortens the time from bug discovery to weaponization, raising the urgency for defenders to patch quickly once technical details become public.

The vulnerability impacts Exim versions 4.97 through 4.99.2 when built against GnuTLS and when the server advertises both STARTTLS and CHUNKING capabilities.

Debian and other distributions that ship Exim with GnuTLS as the default TLS backend are particularly exposed, especially on internet-facing MX hosts that enable TLS and handle large, chunked messages.

Exim 4.99.3 includes a fix that resets the input stack correctly when a TLS close_notify arrives mid-BDAT, preventing stale TLS callbacks from triggering writes into freed memory.

Security trackers and vendors recommend upgrading to 4.99.3 or later as the primary mitigation. Where immediate upgrades are not possible, administrators can reduce risk by:

• Switching Exim builds from GnuTLS to OpenSSL, which is not affected by this particular bug.
• Temporarily disabling BDAT/CHUNKING support, forcing clients back to classic DATA semantics.
• Limiting STARTTLS exposure or enforcing strict access controls on SMTP ports, especially from untrusted networks.

Given the availability of detailed technical write-ups and the demonstrated viability of both human and LLM-assisted exploit chains, organizations running Exim with GnuTLS should treat CVE-2026-45185 as a high-priority remote code execution risk and move quickly to patch or reconfigure vulnerable mail gateways.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.