Exim BDAT use-after-free in GnuTLS builds creates RCE window for mail infrastructure

CVE-2026-45185, designated 'Dead.Letter', represents a use-after-free condition in Exim's handling of the BDAT (binary data) SMTP command. The vulnerability manifests specifically in builds compiled against GnuTLS, suggesting the issue may be related to how that TLS library's memory management or callback semantics interact with Exim's command parsing state machine. Use-after-free bugs in network services are particularly dangerous because they operate on attacker-controlled input paths and frequently result in information disclosure or code execution.

Exim functions as a central component in mail delivery chains across thousands of internet-exposed systems. A remotely triggerable code execution in the SMTP daemon would grant unauthenticated attackers a foothold in mail infrastructure, potentially enabling message interception, spam injection, or pivots into internal networks. The BDAT command is used for binary-safe email transmission and may be less well-tested than traditional SMTP commands, increasing the likelihood that exploitation tooling does not yet exist but eventually will.

The GnuTLS-specific nature of the vulnerability is noteworthy. This suggests the bug may not affect OpenSSL builds, creating a fragmented patch landscape where some administrators remain unprotected despite applying updates. Organisations running Exim with GnuTLS should prioritise patching immediately. Those using OpenSSL should verify whether the underlying logic defect exists in their builds regardless of TLS backend, as the BDAT handling bug may be independent of the trigger condition.

Defenders should: treat Exim as critical infrastructure requiring immediate patch validation; confirm which TLS backend is in use across deployments; apply vendor updates to affected systems without delay; monitor SMTP logs for BDAT commands from untrusted sources as a short-term detection signal; and consider rate-limiting or disabling BDAT support on perimeter MTAs if patches cannot be deployed immediately.

This vulnerability reflects a broader pattern in which memory-safety issues persist in mature, widely-deployed software when development practices do not mandate modern tooling such as memory sanitisers or Rust-based rewrites. The fact that a use-after-free reached production in a component as critical as mail delivery underscores why infrastructure maintainers must treat all RCE vulnerabilities in MTAs as P0 events.