Exim Dead.Letter shows how one mail flaw becomes remote code execution

At a glance

What this is: CYCOGNITO’s analysis of CVE-2026-45185 shows that a use-after-free in Exim’s BDAT path can turn a standard SMTP/TLS exchange into remote code execution on internet-facing mail servers.

Why it matters: This matters because mail relays often sit on the external attack surface with elevated privileges, so exploitability depends as much on exposure and patch discipline as on the flaw itself.

Context

Exim Dead.Letter is a mail server memory-safety issue, not just a protocol bug. A use-after-free in the BDAT parsing path means the daemon can be driven into unsafe memory access during a normal SMTP exchange, which is exactly the kind of failure that becomes dangerous when the service is internet-facing and privileged.

For identity and access teams, the relevance is in how exposed service processes inherit trust. Exim often runs with elevated privileges to bind port 25 and read mail spool directories, so a remote exploit can become a platform-level foothold rather than a contained process crash. That makes server exposure, package provenance, and service hardening part of the same control problem.

The article’s exposure pattern is typical of neglected infrastructure: long-lived mail relays, default protocol features, and uneven patching across distributed estates. That combination is common across shared hosting, legacy on-premises mail, and subsidiary-owned systems.

Key questions

Q: What fails first in Exim Dead.Letter when the vulnerability is triggered?

A: The failure starts in the BDAT parsing path during TLS shutdown, where Exim can free a transfer buffer while the SMTP state machine still references it. That stale reference lets a later cleartext byte corrupt freed heap memory, which is why a routine mail exchange can become remote code execution on a privileged daemon.

Q: Why does this vulnerability matter more on internet-facing mail servers?

A: Because exploitation is unauthenticated and needs only a reachable SMTP service that supports STARTTLS and CHUNKING. On exposed relays, the attacker does not need credentials or user interaction, so the real risk is the combination of default protocol behaviour, privileged process scope, and slow patching.

Q: What signs suggest an Exim deployment may still be exposed?

A: Look for public SMTP listeners that advertise both STARTTLS and CHUNKING, especially where the host runs Exim 4.97 through 4.99.2 with GnuTLS linkage. A package version that looks current is not enough if the running binary has not been verified against the patched code path.

Q: Should teams prioritise patching Exim or restricting SMTP exposure first?

A: Patch first when the server is internet-facing, because the vulnerability is already reachable through normal protocol behaviour. Restricting relay access helps reduce attack surface, but it does not remove the flaw from an externally reachable daemon that still accepts the vulnerable sequence.

Technical breakdown

How the BDAT use-after-free becomes code execution

BDAT is Exim’s support for the SMTP CHUNKING extension, which lets a client stream message bodies in chunks. In Dead.Letter, Exim can free an internal transfer buffer during TLS shutdown while the SMTP state machine still retains a reference to that buffer. If the client then sends one more byte in cleartext on the same connection, the daemon writes into freed memory and corrupts the heap. That corruption is what turns a parsing flaw into arbitrary code execution, because the process continues operating on attacker-influenced memory state.

Practical implication: Treat BDAT and TLS shutdown handling as a remote code execution surface, not a routine mail feature.

Why default SMTP features widen the attack window

The exploit does not require authentication, user interaction, or exotic preconditions. The attacker only needs a TLS connection to an Exim instance that advertises STARTTLS and CHUNKING, both of which are commonly enabled by default on exposed mail servers. That matters because the vulnerable path sits inside standard protocol behaviour, so perimeter exposure directly determines risk. When a service accepts mail from the public internet, the attack window is defined by reachability plus patch lag, not by user behaviour or phishing success.

Practical implication: Inventory every public SMTP listener that advertises CHUNKING and verify its patched status directly.

Why the TLS library path matters for exposure scope

The flaw affects Exim 4.97 through 4.99.2 when built with GnuTLS, while OpenSSL-linked builds are not exposed to this specific path. That makes vulnerability management a build-and-package problem, not just a version-number problem, because distribution defaults shape whether the code path exists. The practical issue is binary provenance: the installed package version may look current while the running build still contains the vulnerable GnuTLS-linked logic. In mixed estates, that is a common blind spot.

Practical implication: Verify the running Exim binary, its TLS linkage, and the distribution security tracker before declaring a host remediated.

Threat narrative

Attacker objective: The attacker’s objective is to execute arbitrary code on exposed Exim servers and gain privileged control over the mail process.

1. Entry occurs when an unauthenticated attacker opens a TLS session to an internet-facing Exim server that advertises STARTTLS and CHUNKING.
2. Credential access is not required because the attacker leverages protocol handling and the TLS shutdown sequence to trigger a use-after-free in the BDAT path.
3. Escalation follows when a final cleartext byte is written into freed heap memory, corrupting the process and enabling arbitrary code execution in the Exim context.
4. Impact is remote code execution on a privileged mail daemon that can read mail spool directories and serve as a foothold on the host.

Breaches seen in the wild

• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Dead.Letter is a service-process trust failure, not just a bug in mail parsing. Exim sits in a privileged position on the edge of many estates, and that privilege turns a memory-safety flaw into an access problem. The important governance question is not only whether the CVE is patched, but whether teams can identify every externally reachable mail process that can be driven through the vulnerable path. Practitioners should treat exposed MTA inventory as part of identity and server governance, not just vulnerability scanning.

The named failure mode here is exposed protocol state with privileged process scope. The article shows a standard SMTP feature becoming dangerous because the daemon holds stale state across TLS shutdown. That is the kind of control gap that slips between application security, infrastructure ownership, and patch management when no one owns the full lifecycle of externally reachable mail services. Practitioners should map this to a concrete service inventory and patch-validation workflow.

Patch verification matters more than package claims in this kind of exposure. The article makes clear that version strings, distribution assumptions, and source-binary differences can all hide residual risk. That means the operational control is not just remediation, but proof of remediation through linkage and build validation. Practitioners should assume that internet-facing mail infrastructure remains a standing exception until the running binary is verified.

Mail infrastructure is part of the external attack surface lifecycle, which many programmes still under-govern. Long-running relays, subsidiary-owned systems, and hosting-provider defaults create a persistence layer that security teams often inherit without clear ownership. The governance lesson is that externally facing infrastructure needs the same lifecycle discipline as user identity and NHI estates: inventory, provenance, patch state, and retirement must be continuously governed. Practitioners should close the ownership gap before the next protocol flaw lands.

Exim Dead.Letter illustrates credential-free compromise of privileged services. That matters because many security programmes still overweight authentication events and underweight remotely reachable daemon logic. When the attacker does not need credentials, identity-centric monitoring alone will not save the host. Practitioners should align perimeter service hardening, patch assurance, and privileged process containment around the exposed daemon, not around login controls.

What this signals

Dead.Letter is a reminder that exposed daemon logic, not just credentials, can create immediate risk. Mail teams should assume that any externally reachable service with elevated privileges deserves the same lifecycle attention as sensitive identity infrastructure. The operational lesson is simple: if the process can be driven through attacker-controlled state, patching and exposure control must be treated as one control plane.

Binary provenance is the practical control that closes the gap here. Teams need to know not only which version they intended to deploy, but which TLS library the running Exim binary actually uses. That is the difference between a paper fix and a real one, especially in estates that mix distro packages, source builds, and inherited hosting infrastructure.

For practitioners

• Verify the running Exim build, not just the package name Confirm the installed binary is linked against the patched code path and that the host is running Exim 4.99.3 or the vendor-fixed package for the relevant distribution.
• Inventory every public SMTP listener Identify internet-facing services on TCP/25, TCP/465, and TCP/587 that advertise STARTTLS and CHUNKING, then prioritise them for immediate validation.
• Remove exposed relay scope where public SMTP is unnecessary Restrict mail server access to known relay peers and internal source ranges when the service does not need to accept the public internet as a client.
• Treat TLS library linkage as part of remediation Check whether each deployment uses GnuTLS or OpenSSL and use that build provenance to confirm whether the vulnerable code path exists on the host.
• Restart and revalidate patched services After applying the distribution security update or upgrading to 4.99.3, restart Exim and recheck the binary and service state before closing the ticket.

Key takeaways

• Dead.Letter shows how a memory-safety bug in a privileged mail daemon can turn standard SMTP handling into remote code execution.
• The exposure problem is amplified by unauthenticated reachability, default CHUNKING support, and distribution-specific build differences.
• Teams should verify the running binary, patch to the fixed release, and reduce public SMTP exposure wherever the service does not need it.

Key terms

• Use-after-free: A use-after-free occurs when code continues to read or write memory after it has already been released. In kernel networking paths, this often becomes a security issue because stale pointers can expose secrets, corrupt control flow, or crash the system under the right timing conditions.
• BDAT: BDAT is an SMTP extension used for chunked message transfer. It changes how mail data is streamed, which means bugs in BDAT handling can affect parsing, buffer ownership, and the state machine that processes incoming mail.
• SMTP State Machine: An SMTP state machine is the logic that tracks what stage a mail session is in and what inputs are valid next. When that state becomes inconsistent with buffer lifetime or TLS teardown, memory-safety flaws can emerge.
• Privileged Mail Daemon: A privileged mail daemon is a mail server process that runs with elevated rights so it can bind low ports, manage queues, or read spool directories. That privilege is operationally convenient, but it also expands the impact of any code execution flaw in the service.

Deepen your knowledge

Build stronger identity and service governance with the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps security practitioners connect privileged processes, lifecycle control, and exposure management across modern estates.