Skip to content

Back to the catalog

XBOW: Dead.Letter (CVE-2026-45185)
xbow.comwriteup

XBOW: Dead.Letter (CVE-2026-45185)

XBOW's detailed technical writeup on CVE-2026-45185, a critical unauthenticated remote-code-execution vulnerability in Exim triggered by a use-after-free during GnuTLS TLS shutdown: Exim frees its xfer_buffer while a nested BDAT chunking receive wrapper can still call the stale tls_ungetc(), writing a single newline byte into freed memory that lands on allocator metadata and escalates to RCE. The post walks through Exim's SMTP/BDAT/TLS receive-callback plumbing and its custom store pool allocator in detail, then narrates a seven-day disclosure-window contest where the researcher (assisted by an LLM) and XBOW's autonomous exploit-development harness raced to build a working exploit chain (glibc largebin corruption, hijacking a malloc call via Exim's spool fdopen, and overwriting a FILE struct) against progressively hardened builds.

TL;DR XBOW's root-cause and exploitation writeup for CVE-2026-45185, an unauthenticated Exim RCE via a GnuTLS-shutdown use-after-free, including a race between a human exploit dev and an autonomous LLM harness to weaponize it.
Open original ↗
Document

What it is

XBOW's technical writeup of CVE-2026-45185, a critical unauthenticated remote-code-execution use-after-free in Exim 4.97 as it ships in default Debian-based installs, specifically Ubuntu 24.04 LTS, when the connection is handled by GnuTLS (the default TLS library on many Debian-based distros). The page beyond the summary pins the exact affected version and the entry point, and doubles as a narrative about the author using an LLM to develop the exploit.

How it works

The trigger path begins with a client issuing STARTTLS over a plaintext SMTP session. Exim's smtp_setup_msg dispatcher handles STARTTLS_CMD, optionally runs the acl_smtp_starttls ACL, then calls tls_server_start() → tls_init(), which allocates a fresh GnuTLS session (gnutls_init(&state->session, GNUTLS_SERVER)). That gnutls_session_t owns all crypto state and the transport callbacks bridging GnuTLS to Exim. During TLS shutdown Exim frees its TLS transfer buffer, but a nested BDAT receive wrapper can still process incoming bytes and call ungetc(), writing a single \n into the freed region. That one byte lands on the allocator's metadata, corrupting its internal shape, which the exploit then leverages into stronger primitives and ultimately RCE.

Preconditions / Affected

  • Exim 4.97 on Debian-based systems including Ubuntu 24.04 LTS, default installation.
  • TLS handled by GnuTLS.
  • The author stresses the key point: triggering requires almost no special server configuration — this, more than the corruption itself, is what makes it one of the highest-caliber Exim bugs to date. The attacker is unauthenticated.

Caveats

  • The primitive looks "deceptively weak" — a single newline byte into freed memory — yet the post claims it escalates all the way to RCE.
  • The fetched text is truncated mid-walkthrough and contains no patch version, mitigation command, or detection guidance; treat this as an explanation of the mechanism and exposure, not a remediation reference. Confirm your Exim version and TLS backend, and track the vendor advisory separately for a fix.

CVEs named here

Technologies named here

Techniques named here

  • Use-after-free via TLS shutdown race with BDAT chunking
  • One-byte heap metadata corruption to escalate to RCE
  • Heap grooming via DKIM-driven allocations
  • Controlled-size heap allocation via SMTP command argument
  • malloc hijack via stdio buffer allocation
  • Heap leak via RCPT TO rejection echoing

Related in AppSec