The Exim project has released an emergency security update that fixes the CVE-2026-45185 use-after-free vulnerability, which leads to heap corruption and potentially allows arbitrary code execution on the mail server. The vulnerability affects all Exim versions from 4.97 through 4.99.2 inclusive that are built with GnuTLS support (build parameter USE_GNUTLS=yes). To exploit it, an attacker only needs to establish a TLS connection and use the SMTP CHUNKING (BDAT) extension—no special server configuration is required. The fix is available in version 4.99.3, there are no alternative mitigation measures, and administrators must update immediately.

Vulnerability mechanism

According to the official Exim security advisory, the vulnerability arises when processing a message body transmitted via the BDAT command, if the client sends a TLS close_notify alert before completing the data transfer and then sends the final byte in plaintext over the same TCP connection. This sequence causes Exim to write data into a memory buffer that was already freed when the TLS session ended, which results in heap corruption.

According to researcher Federico Kirschbaum from XBOW, who discovered the vulnerability, when the TLS session is terminated Exim frees the transmission buffer, but the nested BDAT receive handler continues processing incoming bytes and calls the ungetc() function, which writes a single character (\n) into the already freed memory area. This single-byte write lands on the allocator’s metadata, corrupting its internal structure, which presumably allows an attacker to obtain additional primitives for further exploitation.

Affected versions and exploitation conditions

• Affected versions: Exim 4.97–4.99.2 inclusive
• Condition: build with parameter USE_GNUTLS=yes
• Not affected: builds using OpenSSL or other TLS libraries
• Attacker requirements: ability to establish a TLS connection and use the CHUNKING (BDAT) extension
• Fixed version: Exim 4.99.3
• Exploitation status: at the time of publication there is no data on active exploitation in real-world attacks; the vulnerability is not listed in the CISA KEV catalog

Why this vulnerability is particularly dangerous

Exim is one of the most widely used Mail Transfer Agents (MTA) on Unix-like systems. Mail servers are by nature exposed to the internet and accept incoming connections from arbitrary clients, which makes them an attractive target. The barrier to exploiting CVE-2026-45185 is extremely low: the attacker does not need authentication, no non-standard server configuration is required—only a standard TLS connection with BDAT support, which is enabled by default in modern Exim versions.

It is also noteworthy that the vulnerability is tied to a specific TLS library. Many Linux distributions ship Exim packages built with GnuTLS (for example, Debian and its derivatives traditionally use GnuTLS). Administrators should check which TLS library their Exim instance is built with by running the exim -bV command and looking at the line that indicates the TLS library.

Historical context

This is not the first time critical use-after-free vulnerabilities in Exim related to BDAT handling have been discovered. In 2017, the CVE-2017-16943 vulnerability (CVSS 9.8) in the SMTP daemon was fixed; according to researchers, it allowed unauthenticated attackers to achieve remote code execution via specially crafted BDAT commands. The reappearance of a vulnerability of the same class in the same component nine years later points to the systemic complexity of safely handling state transitions when TLS and streaming data reception interact in Exim’s codebase.

Recommendations

1. Update Exim to version 4.99.3 immediately. According to the advisory, there are no workarounds or temporary configuration changes that eliminate the vulnerability.
2. Determine which TLS library is used: run exim -bV | grep TLS. If the output shows GnuTLS, your server is vulnerable.
3. Audit your SMTP server’s exposure to the internet. Restrict access to ports 25/465/587 at the firewall level where possible without disrupting your mail infrastructure.
4. Review logs for anomalous TLS sessions with premature termination combined with BDAT commands—this may indicate exploitation attempts.
5. Consider rebuilding with OpenSSL as a temporary measure if an immediate update to 4.99.3 is not possible—builds with OpenSSL are not affected by this vulnerability.

The fix in version 4.99.3 correctly resets the input-processing stack when a TLS close_notify alert is received during an active BDAT transfer, preventing the use of stale pointers. Given the lack of alternative protection measures, the low exploitation barrier, and the public availability of technical details about the vulnerability, upgrading Exim to version 4.99.3 should be treated as a top-priority task for all organizations using this MTA with GnuTLS.