Exim maintainers have released version 4.99.3 to fix CVE-2026-45185, a remotely reachable use-after-free in the mail server’s BDAT body parsing path when Exim is built with the GnuTLS backend. The advisory says the flaw can lead to heap corruption and potential code execution, and affects Exim 4.97 through 4.99.x when STARTTLS and CHUNKING are advertised [1].
The bug is worth treating as more than a routine mail-server patch. XBOW, which reported the issue and named it Dead.Letter, describes it as an unauthenticated RCE path: during TLS shutdown, a nested BDAT receive wrapper can still process bytes and write a newline into freed memory, giving the exploit a path from a small memory corruption primitive to code execution [2]. That puts internet-facing MTAs, shared hosting nodes, and control-panel mail stacks in the practical risk zone.
What Exim Admins Should Check First
The first decision is whether the server matches the vulnerable shape, not whether it merely has Exim installed. Check the installed Exim version, then confirm how the package was built and whether the public SMTP service advertises both STARTTLS and CHUNKING. The TLS library detail matters because the advisory scopes the issue to GnuTLS builds. On managed platforms, including hosting environments where Exim is bundled with a control panel, use the vendor or distro security update path rather than swapping in an upstream binary that may break mail routing, authentication, or panel-managed configuration.
The second decision is exposure. A mail server usually cannot be hidden from the internet without breaking delivery, so the practical containment path is fast package deployment, restart validation, and log review. Look for unusual SMTP sessions around STARTTLS and BDAT, Exim crashes, paniclog entries, core dumps, or abrupt TLS shutdown patterns. These signals are not proof of exploitation by themselves, but they help decide whether the server needs only patch verification or a wider incident review.
If the server was vulnerable and exposed, treat it as a possible mail-server compromise until logs say otherwise. Review Exim configuration files, transport/router changes, cron jobs, new system users, SSH keys, and web-accessible directories on the host. This is especially important on hosting servers, where mail compromise can sit next to web shells or control-panel abuse; Gridinsoft recently covered a separate cPanel exploitation chain that deployed a Filemanager backdoor, which is the same operational lesson in a different component.
There is also useful context from older Exim incidents. In 2023, Gridinsoft covered an Exim RCE issue that initially had no patch available; this time, the fix is already public, so the priority is inventory and deployment speed. STARTTLS remains important for email confidentiality, so workaround decisions such as changing advertised SMTP capabilities should be treated as temporary, tested controls rather than a replacement for Exim 4.99.3 or a distro backport.
