9.8 Critical Alert: One-Byte Heap Corruption in Exim Exposes Global Mail Servers to Takeover

A “highest-caliber” vulnerability was found in Exim, one of the internet’s most widely used Mail Transfer Agents (MTAs). Tracked as CVE-2026-45185 with a CVSS score of 9.8, this flaw exposes thousands of servers to remote heap corruption and potential takeover.

The bug targets Exim’s integration with the GnuTLS backend, specifically during the handling of large email body transfers.

Discovered and reported on May 1, 2026, by Federico Kirschbaum of the autonomous testing platform XBOW, the vulnerability relies on a highly specific—yet easily repeatable—sequence of network events.

The attack occurs when a malicious client uses the CHUNKING (BDAT) SMTP extension over an encrypted TLS connection. The exploit is triggered through the following steps:

1. The client sends a TLS close_notify alert before the email body transfer is actually finished.
2. The attacker immediately follows up with a final byte sent in cleartext over the same TCP connection.
3. During the TLS shutdown, Exim correctly frees its transfer buffer. However, a “nested BDAT receive wrapper” continues to process the incoming cleartext byte.
4. This wrapper calls a function (ungetc()) that writes a single character—a newline (\n)—into the memory region that was just freed.

As Kirschbaum explained, “That one-byte write lands on Exim’s allocator metadata, corrupting the allocator’s internal shape”. This seemingly tiny corruption allows an attacker to gain the “primitives” necessary for a full-scale exploit.

This vulnerability is library-specific.

• All Exim versions from 4.97 up to and including 4.99.2.
• Only builds compiled with USE_GNUTLS=yes are vulnerable.
• Installations using OpenSSL or other TLS libraries are unaffected by this specific flaw.

Perhaps most concerning is that triggering the bug “requires almost no special configuration on the server” beyond the default ability to establish a TLS connection and use BDAT.

Exim has moved swiftly to address the vulnerability with the release of version 4.99.3. The fix works by ensuring the input processing stack is completely reset the moment a TLS close notification is detected during an active transfer. This effectively kills the “stale pointers” before they can be misused to write into freed memory.