An AI Found a Use After Free Bug in Exim—the Mail Server Behind More Than Half the Public Internet—And Triggering It Takes a Single Stray Byte at the Wrong Moment

On May 12, 2026, the Exim team shipped version 4.99.3 with a quiet advisory describing a use after free vulnerability in the mail server's binary data transmission handler. The advisory does not call it Dead.Letter, but the researcher who found it does, and the name fits the bug: Exim writes a single byte to memory it has already given back to the system, after the connection that was supposed to deliver an email closes early.

The byte is the letter n. Specifically, the newline character pushed back onto Exim's input buffer by a function called ungetc(). It lands in freed memory. From there, an unauthenticated attacker who can open a TLS connection to port 25 can shape the heap into something Exim never meant to execute.

How Much of the Internet Is Exim

Exim is the Mail Transfer Agent the average internet user has never heard of, and the one their mail probably passes through. Studies of publicly reachable SMTP servers have consistently put Exim's share above 55 percent, with some scans putting it as high as 59 percent. The number is so high because cPanel, the dominant shared hosting control panel, bundles Exim by default. Every reseller, every small ISP, every hobbyist VPS that turned on email is running it.

That installed base is the context for CVE-2026-45185. Postfix and Sendmail are not vulnerable. The handful of cloud-first deployments that pick their MTA on purpose lean toward those. Exim's dominance is bottom up: it is the default that hosting companies installed on millions of servers a decade ago and never replaced. Those are the boxes at risk now.

The Bug, in the Sequence That Triggers It

The flaw lives in Exim's handling of the SMTP CHUNKING extension, also known as BDAT. CHUNKING lets a client deliver a message body in declared-length chunks instead of streaming it until a terminating CRLF.CRLF. It is the modern way to send large or binary email. Federico Kirschbaum, Security Lab head at XBOW, walked through the exact sequence in his disclosure:

1. The attacker opens an SMTP connection over TLS and advertises CHUNKING support.
2. The attacker sends a BDAT command declaring a body of N bytes, then begins streaming the chunk over the encrypted channel.
3. Mid-transfer, before the chunk is complete, the attacker sends a TLS close_notify alert.
4. The attacker then writes one final byte in cleartext on the same TCP connection.

During the TLS shutdown that Exim initiates in response to the close_notify, the server frees the TLS transfer buffer. But the nested BDAT receive wrapper has not been told to stop. It processes the trailing cleartext byte and calls ungetc() to push a newline back into the buffer it just freed. One stray write to dead memory. From there, heap shaping does the rest.

Kirschbaum called it "one of the highest-caliber bugs" he had seen in Exim and emphasized that "triggering it requires almost no special configuration on the server."

Who Is Actually Affected

The advisory narrows the exposure on two axes. Version: Exim 4.97 through 4.99.2 inclusive. TLS library: only builds compiled with USE_GNUTLS=yes. OpenSSL builds of the same Exim versions are not vulnerable, because the bug lives in how Exim drives the GnuTLS shutdown path.

That sounds narrow until you check what shipped on which distribution. Several Debian and derivative builds default to GnuTLS for Exim. So do a number of cPanel images. Anyone who installed Exim from a distribution package rather than recompiling it has roughly a coin-flip chance of running the GnuTLS variant, and no easy way to know without checking the build flags.

There are no workarounds. The fix is in 4.99.3, which clears the input processing state when a TLS close notification arrives during an active BDAT transfer. If your operator is more than one patch cycle behind, this is the patch to chase down. CHUNKING is enabled by default. Authentication is not required. The attacker needs nothing but a network path to port 25 or 465.

Why the Source of the Discovery Matters

Kirschbaum did not find this bug by hand. He found it with XBOW, an autonomous offensive security platform that fuzzes and reasons about software the way a human pen tester would, but without sleeping. This is the second consecutive Patch Tuesday cycle in which an AI driven research program has surfaced a critical bug in long-audited infrastructure. Microsoft's own MDASH system found 16 Windows flaws in this month's release, including the BitLocker zero day with public proof of concept.

Exim is one of the most scrutinized pieces of software on the internet. Its codebase has been read by hostile state actors and friendly security researchers for thirty years. A previous critical use after free bug, CVE-2017-16943, hit the same BDAT command surface in 2017. The pattern of "Exim plus binary data transmission plus memory corruption" was a known concern. It still took an autonomous agent to find the next instance.

The implication for defenders is uncomfortable: the time between a vulnerable code path landing in a stable release and an AI agent producing a working exploit is collapsing. Every patch cycle that used to be "we will get to it next quarter" is now a race condition.

What an Attacker Gets From an Exim Box

A compromised mail server is not just a relay. It is a position inside the trust boundary of every domain it handles. From a single owned Exim host an attacker can:

• Read every message in transit. Outbound mail from every tenant on a shared hosting box passes through one Exim process. So does mail to local accounts.
• Send mail signed by every domain. Exim holds the DKIM private keys for the domains it serves. Anyone with root on the box can forge mail that passes SPF, DKIM, and DMARC for hundreds of customers at once.
• Pivot into customer accounts. Password reset emails are routed through the same server. An attacker who controls Exim controls the second factor for every web app whose recovery flow goes through email.
• Plant persistent tracking in legitimate mail. A compromised MTA is the ideal place to inject tracking pixels into mail in transit, because the mail still looks like it came from the original sender and the recipient's anti-spoofing checks pass.

Why Email Users Should Care

Dead.Letter is the kind of bug that does not need to be marketed. State actors and ransomware operators read the Exim advisory the same day defenders did. Shodan and Censys snapshots of port 25 already show banner versions for hundreds of thousands of unpatched servers, and historical Exim disclosures have produced mass scanning campaigns within hours.

If you run mail infrastructure, the action is straightforward: identify any Exim host on 4.97 through 4.99.2, confirm whether it was compiled against GnuTLS, and upgrade to 4.99.3. If you are a tenant on shared hosting, the action is asking your provider when they patched, and treating the answer as a security signal.

For everyone else, the takeaway is the one nobody likes: the mail that lands in your Gmail inbox passed through a long chain of servers, many of which are running software older than your phone. Every link in that chain is a point where messages can be read, modified, or laced with the tracking pixels that still drive the email surveillance economy in 2026. Patching Exim closes one door. Blocking the pixels and click trackers on the recipient side closes the one that opens every time you read a message.