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

At a glance

What this is: This is an analysis of a critical Exim use-after-free vulnerability that can enable remote code execution on internet-facing mail servers.

Why it matters: It matters because mail infrastructure often sits outside tight identity governance, yet it still runs privileged services that can be reached, abused, and turned into persistence or exfiltration points.

By the numbers:

• Exim CVE-2026-45185 carries a CVSS v3.1 base score of 9.8, reflecting a critical unauthenticated remote code execution risk.
• Exim 4.97 through 4.99.2 are affected when compiled with USE_GNUTLS=yes, concentrating exposure on GnuTLS-backed deployments.
• Debian and Ubuntu distributions shipped coordinated fixes for affected Exim packages on May 12, 2026, reducing exposure for patched systems.

👉 Read CYCOGNITO's analysis of Exim CVE-2026-45185 and Dead.Letter exposure

Context

Exim Dead.Letter is a classic example of how a low-level parser flaw becomes an external attack path when a service is internet-facing and trusted by design. In this case, the primary issue is not email as a business function, but the combination of exposed SMTP, default protocol features, and a privileged daemon that handles untrusted input on behalf of the organisation.

For identity and access teams, the relevance is indirect but real. Mail servers often sit outside central IAM and PAM oversight, yet they still rely on service accounts, privileged service contexts, and operational trust assumptions that can be converted into broader compromise when code execution is possible. That makes mail infrastructure part of the access boundary, not just the network perimeter.

The exposure pattern described in the article is typical for legacy mail infrastructure, especially where ownership is diffuse and patch verification is weak.

Key questions

Q: What fails when a mail server has an exploitable parser bug and broad internet exposure?

A: The failure is not only code execution. It is the collapse of trust around a privileged, externally reachable service that can read mail, relay traffic, and become a foothold for deeper compromise. Once the parser bug is reachable over the network, operational continuity and confidentiality both become incident concerns, not just patching issues.

Q: Why do privileged SMTP services increase blast radius after exploitation?

A: Because mail daemons often run with rights that exceed their narrow function. They need access to low ports and mail spools, so a successful exploit can expose queued messages, alter delivery paths, or support lateral movement. That makes least privilege and process isolation central to mail server governance.

Q: How can security teams tell whether Exim exposure is actually under control?

A: They should verify three things: the installed build is patched, the running binary matches the patched code, and the exposed SMTP surface is limited to systems that genuinely need public access. If any of those checks fail, the risk remains active even after a nominal update.

Q: Who is accountable when a vulnerable mail relay stays exposed after a fix is available?

A: Accountability should sit with the service owner, the platform team, and the patch governance process together. A public-facing relay is an operational asset, so failure to verify binary state, exposure scope, and service ownership is a control breakdown across operations and security, not a single-team issue.

Technical breakdown

How the BDAT parsing bug turns into heap corruption

Dead.Letter is a use-after-free in Exim’s BDAT message body parsing path. The vulnerable sequence appears when Exim is using the GnuTLS-backed TLS path and receives a TLS close_notify while still processing a chunked message transfer. Exim frees an internal buffer, but the SMTP state machine still keeps a live reference to it. If the attacker sends one final byte in cleartext over the same TCP connection, Exim writes into freed memory and corrupts the heap.

Practical implication: patch the parser path, not just the package label, because the exploit hinges on a specific runtime code path.

Why internet-facing SMTP defaults widen the attack surface

The flaw is exploitable without authentication and without user interaction, which means the attacker only needs network reachability to an SMTP listener advertising STARTTLS and CHUNKING. Those features are common on public mail relays and are enabled by default in many Exim deployments. That matters because SMTP is not usually treated like an interactive application, so external exposure can persist long after operators believe a server is merely passively relaying mail.

Practical implication: inventory every exposed SMTP listener and verify whether it advertises both STARTTLS and CHUNKING.

Why privileged mail daemons raise the blast radius

Exim commonly runs with elevated privileges so it can bind port 25 and access local mail spools. Once arbitrary code execution is achieved in that process context, the attacker may be able to read queued mail, tamper with routing, or pivot into adjacent systems that trust the relay. The vulnerability therefore reaches beyond availability and into confidentiality and post-exploitation persistence, which is why mail daemons must be treated as high-value external services.

Practical implication: constrain relay permissions and monitor the mail process as a privileged workload, not a routine utility.

Threat narrative

Attacker objective: The attacker’s objective is remote code execution on a privileged mail server to read, alter, or leverage mail infrastructure for deeper compromise.

1. Entry occurs when an unauthenticated attacker connects to an internet-facing Exim server over SMTP and negotiates the exposed STARTTLS and CHUNKING features.
2. Escalation occurs when the attacker triggers the GnuTLS shutdown path, causing Exim to free a buffer while the state machine still references it, then overwrites freed heap memory with a final cleartext byte.
3. Impact occurs when the corruption is turned into arbitrary code execution in the Exim process, which can expose mail contents and enable further compromise.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Exposed mail infrastructure is still identity-adjacent infrastructure. SMTP relays are often excluded from identity programmes until something goes wrong, yet they run privileged services, handle trusted routing, and depend on operational accounts and release processes. When a parser flaw turns into code execution, the boundary between infrastructure security and access governance collapses. Practitioners should treat externally reachable mail servers as governed assets, not orphaned utilities.

Dead.Letter is a standing exposure window problem, not just a patch problem. The control failure is the assumption that long-lived internet services remain safe if they are operationally stable. In reality, stability often masks unverified package state, legacy protocol support, and weak binary provenance checks. A service that looks unchanged can still be exploitable if the linked TLS stack and parser path are not validated after remediation.

Privileged service execution amplifies the impact of otherwise narrow bugs. Exim’s need to bind low ports and access mail spools means exploitation can yield more than a crash. That is the same governance lesson seen across service accounts and workload identities: when a process has more rights than its immediate function requires, any memory corruption or command execution bug becomes a broader trust failure. The practitioner conclusion is to minimise runtime privilege and isolate mail functions.

Mail security now intersects with workload identity discipline. Even though this is a vulnerability story, the operational lesson is consistent with NHI governance: services that authenticate, relay, or broker data should have tightly bounded execution context, explicit ownership, and verified patch state. Exposed infrastructure that is not continuously accounted for becomes invisible to access governance until it is already part of an incident response. The field should treat mail servers as part of the identity surface.

Protocol complexity is the named concept this flaw exposes. Dead.Letter shows how layered protocol behaviour, TLS shutdown handling, and application parsing can create a control gap that no perimeter rule can see. When a service mixes encrypted and cleartext states on one connection, the security boundary is the code path itself. Practitioners should prioritise binary verification and protocol-minimising exposure over assumptions about network trust.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• That same research found DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records.
• Forward pivot: Our The 52 NHI breaches Report shows how quickly exposed credentials and service trust assumptions become incident paths once external reachability is present.

What this signals

Exposed mail relays should now be treated as part of the organisation’s external identity surface, because privileged services with network reach behave like access paths even when they are not managed as identities. The operational lesson is to verify binary provenance, service exposure, and runtime privilege together instead of assuming a timely patch closes the risk.

Protocol complexity becomes a governance signal: when one code path mixes TLS shutdown, chunked transfer handling, and privileged execution, the control question is no longer just whether the server is patched. Practitioners need a repeatable way to prove that the live service, its linked libraries, and its exposure model match the intended security state.

Teams that already track service accounts and workload identities should extend that discipline to mail infrastructure, because the same ownership and lifecycle failures that affect NHIs also affect privileged daemons. The practical signal is simple: if you cannot name the owner, confirm the binary, and justify the exposure, the asset is not under control.

For practitioners

• Verify the patched binary, not just the package version Confirm the running Exim binary is linked against the fixed code path after upgrading to 4.99.3 or a distribution security build. Package strings alone do not prove the live process is safe.
• Inventory every externally reachable SMTP listener Map servers on TCP/25, TCP/465, and TCP/587 that advertise STARTTLS and CHUNKING, then classify which are truly required to accept public mail.
• Restrict relay reachability where public access is unnecessary Limit SMTP access to known relay peers on systems that only need internal or partner mail flow, and remove unnecessary exposure from the internet.
• Reduce privilege in mail service operations Review the permissions granted to the mail process, the spool directories it can read, and the operational accounts that can restart or manage it.

Key takeaways

• Exim Dead.Letter shows that a single parser bug can become full remote compromise when an internet-facing service processes untrusted traffic with elevated privileges.
• The article’s exposure model is operationally familiar, with unauthenticated access, default-enabled protocol features, and delayed patch verification combining to widen the attack window.
• The limiting controls are straightforward: verify the live binary, reduce unnecessary SMTP exposure, and treat privileged mail servers as governed assets rather than background infrastructure.

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 Parsing Path: The BDAT parsing path is the portion of an SMTP server that handles chunked message body transfer. When this path is exposed to untrusted network input, parsing errors can become remote attack vectors, especially if they occur inside privileged mail services.
• 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.

What's in the full report

CYCOGNITO's full analysis covers the operational detail this post intentionally leaves for the source:

• Package-level remediation guidance for Debian and Ubuntu builds, including version validation steps
• The exact Exim build conditions that trigger the vulnerable GnuTLS code path
• Exposure mapping guidance for TCP/25, TCP/465, and TCP/587 listeners
• Practical verification steps for confirming the patched binary is the one actually running

👉 CYCOGNITO's full post covers affected versions, fix validation, and exposure checks for internet-facing mail servers.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in operational contexts. It helps practitioners connect service trust, access boundaries, and lifecycle control across identity programmes.