Exim 'Dead.Letter' RCE: GnuTLS builds at risk
Just saw the drop regarding CVE-2026-45185 (dubbed "Dead.Letter"). This is a critical use-after-free vulnerability in Exim that could lead to RCE, but there's a catch: it specifically targets builds using GnuTLS.
The vulnerability triggers when processing BDAT (Binary Data) chunks. The specific flaw allows an attacker to manipulate the state of the TLS interaction layer in GnuTLS, causing the receive_msg() function to access memory that has already been freed.
Unlike OpenSSL builds where the handling logic differs, GnuTLS implementations are susceptible to this corruption.
Checking your exposure
Before you panic, verify your build. Most modern Linux distros compile Exim against OpenSSL, but older or custom builds might use GnuTLS. Run this to confirm:
exim -bV | grep -E "GnuTLS|OpenSSL"
Detection
Since UAF bugs can be unstable, you might see crashes before you see shell activity. Watch your logs for segmentation faults tied to incoming SMTP connections:
grep -i "segmentation fault\|sigsegv" /var/log/exim4/mainlog
If you see crashes around the time of high SMTP traffic, investigate immediately.
Remediation
Patching is the only reliable fix here. Snort/Suricata rules for BDAT anomalies are hit-or-miss due to legitimate bulk mail usage.
For those managing mixed environments, are you considering blocking BDAT commands as a temporary stopgap until patches are deployed to legacy systems?
I would strongly advise against blocking BDAT entirely. It's part of the RFC and breaks chunking for legitimate senders, which will cause massive mail delivery delays for your users.
If you can't patch immediately, at least enforce strict TLS verification and rate limit the number of BDAT chunks per session. This doesn't fix the bug, but it makes the memory management slightly more predictable and harder to hit reliably with a spray-and-pray exploit.
Just verified our estate— thankfully we are standard on OpenSSL builds so the impact is null for us, but this is a reminder to check custom compiled MTAs.
For anyone using Suricata, I'm testing a custom rule looking for BDAT chunks that exceed the advertised message size (SIZE argument). It's a heuristic, but it catches the PoC scripts I've seen floating around.
# Rule example for testing
alert tcp $HOME_NET any -> $EXTERNAL_NET 25 (msg:"BDAT Size Mismatch"; flow:to_server,established; content:"BDAT"; pcre:"/BDAT\s+(\d+)\.*/R"; ...)
Validating the build configuration is the immediate priority. If you're unsure whether your instances are vulnerable, run this command to check the linked TLS libraries:
exim -bV | grep -E "(GnuTLS|OpenSSL)"
If GnuTLS appears, patch immediately. In the meantime, strict rate-limiting on BDAT commands might offer a temporary mitigation without breaking RFC compliance entirely.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access