Critical Use-After-Free Flaw in Exim MTA Exposes GnuTLS Mail Servers to Remote Code Execution

Exim has released an emergency patch for a severe use-after-free vulnerability that affects all builds of the widely deployed open-source Mail Transfer Agent (MTA) compiled with GnuTLS. The flaw, tracked as CVE-2026-45185 and named Dead.Letter, carries the potential for heap corruption and remote code execution on unpatched mail servers.

Exim is one of the most widely deployed MTAs on the internet, used extensively across enterprise, government, and hosting environments to receive, route, and deliver email.

How the vulnerability works

The flaw is triggered during BDAT (binary data transmission) message body handling when a client sends a TLS close_notify alert before the body transfer is complete, then follows up with a final byte in cleartext on the same TCP connection. This sequence causes Exim to write into a memory buffer that has already been freed during TLS session teardown.

Federico Kirschbaum, head of Security Lab at XBOW, who discovered and reported the flaw on 1 May 2026, described the technical mechanism as follows: during TLS shutdown, Exim frees its TLS transfer buffer, but a nested BDAT receive wrapper can still process incoming bytes and call ungetc(), writing a single character into the freed region. That single byte lands on the allocator's internal metadata, corrupting it and providing an attacker with a foothold for further exploitation primitives.

XBOW characterised the bug as among the highest-calibre vulnerabilities discovered in Exim to date.

Scope and affected versions

• Affected versions: Exim 4.97 through 4.99.2
• Condition for exploitation: the build must use USE_GNUTLS=yes
• Builds compiled against OpenSSL are not affected
• An attacker only needs to establish a TLS connection and use the CHUNKING (BDAT) SMTP extension. No special server configuration is required on the target.

Patch and remediation

Exim has released version 4.99.3, which resolves the vulnerability by ensuring the input processing stack is cleanly reset when a TLS close notification is received during an active BDAT transfer, preventing stale pointers from being accessed.

There are no mitigations that resolve this vulnerability. The only remediation is upgrading to 4.99.3.

Why GCC and MENA enterprises should act now

For organisations running self-hosted mail infrastructure across the Gulf region, this vulnerability demands immediate attention. Exim-based systems operating in enterprise, government, and service provider environments that use GnuTLS are exposed to a remotely exploitable code execution path through a standard SMTP extension.

This is not an obscure edge case. Application security in the GCC is a growing concern as software becomes the primary attack surface. BDAT/CHUNKING support is commonly enabled in enterprise mail configurations, and TLS is expected on any compliant deployment. The attack surface is accessible to any party that can initiate a TLS connection to the mail server.

Administrators should:

1. Confirm which TLS library their Exim build uses (check build configuration or run exim --version)
2. If GnuTLS is in use, schedule immediate upgrade to 4.99.3
3. Where upgrade is not immediately feasible, consider restricting BDAT/CHUNKING in SMTP policy as a temporary measure, with the understanding that this is not a security fix
4. Review mail server logs for anomalous BDAT sequences as a precautionary step

This is not the first time Exim has been affected by critical use-after-free vulnerabilities. In late 2017, CVE-2017-16943, a CVSS 9.8 flaw also involving BDAT commands, allowed unauthenticated attackers to achieve remote code execution. The recurrence of this class of vulnerability in the same code path makes patch urgency clear.