XBOW Discloses 'Dead.Letter' Use-After-Free in Exim's BDAT Path, CVSS 9.8 Pre-Auth RCE Against GnuTLS Builds 4.97 to 4.99.2
CVE-2026-45185, found by XBOW's Federico Kirschbaum and patched in Exim 4.99.3, lets an unauthenticated SMTP client corrupt the heap via a TLS close_notify during a CHUNKING transfer.
Overview
Exim maintainers shipped version 4.99.3 on May 12 to fix a remotely reachable use-after-free in the mail transfer agent’s BDAT body parser, a flaw disclosed by autonomous security firm XBOW under the name Dead.Letter. According to The Hacker News, the bug is tracked as CVE-2026-45185 and affects every Exim release from 4.97 through 4.99.2 when the server is built with GnuTLS. CIRCL’s vulnerability database assigns the issue a CVSS 3.1 base score of 9.8 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, classified under CWE-416, according to CIRCL Vulnerability Lookup.
What We Know
The official NVD-style description from CIRCL reads: “Exim before 4.99.3, in certain GnuTLS configurations, has a remotely reachable use-after-free in the BDAT body parsing path. It is triggered when a client sends a TLS close_notify mid-body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection. This can lead to heap corruption. An unauthenticated network attacker exploiting this vulnerability could execute arbitrary code,” as published by CIRCL Vulnerability Lookup.
The trigger sequence is narrow but unauthenticated. The vulnerability “is triggered during BDAT message body handling when a client sends a TLS close_notify alert before the body transfer is complete, and then follows up with a final byte in cleartext on the same TCP connection,” according to The Hacker News. The same outlet notes the attack “is remotely reachable over SMTP and does not require authentication, valid recipients, or user interaction.”
XBOW’s writeup, co-authored by Federico Kirschbaum and Andres Luksenberg, details the mechanism at the buffer level: during TLS teardown Exim frees its transfer buffer, xfer_buffer, while a nested BDAT receive wrapper retains a stale pointer to tls_ungetc(). When that stale function pointer is invoked it “writes a single character (\n) into the freed region,” which “lands on Exim’s allocator metadata, corrupting the allocator’s internal shape,” according to XBOW. The authors call the resulting primitive deceptively small: “The write primitive might seem deceptively weak at first glance: it puts a single newline character into a freed memory region. But as the rest of this post will show, that one byte is enough to escalate all the way to remote code execution.”
XBOW’s research team demonstrated working exploit chains starting from that single-byte write. Without ASLR or PIE, the chain corrupts glibc largebin pointers, hijacks a malloc(4096) allocation backing a stdio FILE struct, overwrites the vtable, and pivots through FSOP gadgets into a ROP payload. With ASLR enabled, the chain shifts to Exim’s own pool allocator: it inflates a storeblock length field with the single-byte corruption, uses string parsing commands as memory layout opcodes, and ultimately overwrites ACL pointers to invoke embedded ${run} payloads, according to XBOW.
The disclosure timeline, as documented by XBOW, is tight. The vulnerability was submitted to security@exim.org on May 1; maintainers acknowledged on May 5 and noted a private fix was already in progress; the CVE was assigned on May 10; and the public release with coordinated distribution rollout landed on May 12, per the same XBOW post. Exim release engineer Heiko Schlittermann posted the maintainer announcement to the oss-security list at 16:15 +0200 on May 12, describing the bug as “a remotely reachable Use-After-Free (UAF) vulnerability” that “can lead to heap corruption and potential code execution,” affecting “Exim 4.97 through 4.99.x configured with GnuTLS support and STARTTLS/CHUNKING advertised.” The post confirms “Distros already have coordinated access to patches” and credits “the reporter at xbow security” under tracking ID EXIM-Security-2026-05-01.1, according to Openwall.
Field Effect’s intelligence team adds that maintainers “coordinated disclosure with distributors between May 7-10,” and that the bug primarily affects Debian, Ubuntu, and Debian-derived distributions because GnuTLS is the default TLS backend there, according to Field Effect. OpenSSL-linked builds are not exposed. FOSS Force reports that no workaround exists and that operators must upgrade to 4.99.3, characterizing the bug as “one of the highest-caliber bugs discovered in Exim to date” in remarks attributed to Kirschbaum and Luksenberg, according to FOSS Force.
What We Don’t Know
No public reporting cited here gives an estimate of how many production Exim servers are running affected GnuTLS builds or how many have already applied 4.99.3. The XBOW writeup discloses the primitive and demonstrates two chains in controlled environments, but does not claim any in-the-wild exploitation. Whether the bug has been independently weaponized outside the disclosure window is not addressed in the sources reviewed.
XBOW is the same firm that, as previously reported, closed a $120 million Series C in March at unicorn valuation to scale its autonomous offensive-security platform. In the Dead.Letter post, Kirschbaum, who introduces himself as a researcher who has “spent almost ten years writing exploits professionally, and twenty in security altogether,” frames the work as a test of LLM-assisted exploitation: “LLMs can compress the early stages of vulnerability research,” he writes, but “the hard parts are still hard. You still need taste. You still need skepticism. You still need to debug,” according to XBOW.