AI Security

Dead.Letter: XBOW's AI Beat the Human to an Exim RCE Exploit

XBOW disclosed a CVSS 9.8 unauthenticated RCE in Exim, then raced an autonomous LLM against a human to weaponize it. In the controlled challenge the machine finished a working exploit; the human didn't. That's the real signal in the shrinking n-day window.

Nicholas Robert

Nicholas Robert

— 5 min read
Share
Line-art illustration of a digital envelope with a severed padlock seal, depicting the Exim Dead.Letter CVE-2026-45185 remote code execution flaw.

The headline on CVE-2026-45185 writes itself: a CVSS 9.8, unauthenticated remote-code-execution bug in Exim, the mail transfer agent that still moves a majority of the internet's email. Patch to 4.99.3 and move on. But the reason this particular flaw — nicknamed Dead.Letter — is worth more than a patch note is what XBOW did with the seven-day disclosure window. It turned that window into a stopwatch and raced a human exploit-writer against a fully autonomous large language model. The machine's result is the part the wire copy buried.

XBOW is the autonomous offensive-security system that spent 2025 climbing to the top of HackerOne's US researcher leaderboard. Federico Kirschbaum, who heads its security lab, reported the Exim use-after-free to the project on May 1, 2026; the coordinated fix landed on May 12. In between, XBOW ran an internal experiment — hand the same freshly-patched bug to a person and to an LLM set loose “to develop the exploit end to end, fully autonomous,” and see who reaches working code first. The answer complicates the comfortable story that AI can find bugs but still needs a human to weaponize them.

●  THE n-DAY WINDOW IS COLLAPSING
When a machine can weaponize a patch in the same week it ships, the gap between disclosure and mass exploitation shrinks toward zero.
DISCLOSURE
Exim ships 4.99.3 and publishes CVE-2026-45185. The patch diff is itself a map to the freed-buffer bug.
↓
THE OLD, HUMAN-PACED CURVE
Turning a one-byte heap use-after-free into reliable code execution was days-to-weeks of craft work. That labor cost was a defensive subsidy.
↓
AI-PACED EXPLOIT DEV
Inside the same seven-day window, XBOW’s autonomous LLM wrote a working exploit for a CTF-shaped build — the human got only a memory leak.
↓
SHRINKING DEFENDER WINDOW
As machine exploit-gen matures toward hardened targets, mass exploitation can start before slow-moving mail servers are ever patched.
Source: XBOW Dead.Letter write-up; Exim advisory, CVE-2026-45185 (CVSS 9.8).

What the Bug Actually Is

Exim's BDAT command lets a client stream a message body in pre-declared chunks instead of ending it with the usual CRLF.CRLF terminator. On builds that use the GnuTLS backend — the default on Debian and Ubuntu — a client can send a TLS close_notify alert mid-transfer, which makes Exim free its TLS transfer buffer, and then keep feeding bytes on the same connection. A nested BDAT receive wrapper still processes those bytes and calls ungetc(), writing a single newline into the just-freed region. That one-byte write into freed heap memory (CWE-416) is the seed of an unauthenticated RCE.

The flaw affects Exim 4.97 through 4.99.2 and is fixed in 4.99.3. It requires the GnuTLS backend plus STARTTLS and CHUNKING advertised — which sounds narrow until you realize that combination is the default for most Linux mail-server packages. OpenSSL builds follow a different teardown path and are not affected. As of writing, a public detection script exists on GitHub, but no confirmed in-the-wild exploitation has been reported.

The Race XBOW Actually Ran

Here the tidy version of this story — including our own first pass at it — got the outcome backwards. The comfortable telling says the humans won and the machine got close. XBOW's own write-up says something more unsettling. The autonomous system, “XBOW Native,” produced working exploits against controlled builds of the target: first with ASLR and PIE disabled, using largebin corruption, a FILE-struct hijack and an FSOP/ROP chain; then, harder, with ASLR enabled, by corrupting Exim's custom allocator with roughly 200 crafted SMTP commands to plant attacker-controlled ACL text and reach code execution through ${run} expansion. The human researcher, working the same window, achieved a stack-address leak but did not finish a full working exploit.

The caveat matters as much as the result. These were CTF-shaped conditions — simplified builds with mitigations dialed down, not a hardened production Exim on a live network. XBOW's own engineer is blunt about the ceiling: “I don't think LLMs alone are quite ready to write exploits against real-world software yet ... it can solve something CTF-shaped, but I don't see them reaching the level of real production targets just yet.” So the machine didn't beat the human at attacking the real internet. It beat the human at a constrained version of the same problem — a different claim, and still a large one.

My Read

The interesting number in Dead.Letter isn't 9.8. It's the collapsing distance between a patch shipping and a working exploit existing. For decades the n-day window — the gap between public disclosure and mass exploitation — was governed by human labor. A heap use-after-free like this one is exactly the class of bug that used to buy defenders time, because turning a one-byte freed-heap write into reliable code execution is craft work that takes a skilled person days to weeks. That labor cost was, in practice, a defensive subsidy.

Autonomous exploit-generation attacks that subsidy directly. XBOW's result says the easy-to-medium rungs of the craft — triage, primitive-finding, strategy enumeration, and now full exploitation of simplified targets — are being automated first. The hardened-production rung still needs a human. But the trend line only points one way, and defenders should plan for the version where the human isn't required. When the exploit can be generated in the same week the patch drops, “we'll get to it next maintenance window” stops being a risk decision and becomes a bet. It's the same pattern XBOW's tooling has shown before — see our coverage of the NGINX Rift finding, where a machine surfaced a deep, long-buried bug at a speed no human triage team matches.

What Defenders Should Do

  • Patch Exim to 4.99.3 now. Prioritize internet-facing mail servers on GnuTLS builds. The bug is pre-authentication and network-reachable, so there is no login step to slow an attacker down.
  • Check your TLS backend first. Run “exim -bV”: GnuTLS builds are exploitable, OpenSSL builds are not. That single fact re-ranks your whole fleet by real exposure.
  • Mitigate if you truly can't patch yet. On GnuTLS hosts, disable CHUNKING advertisement (set chunking_advertise_hosts to an empty list). STARTTLS can stay — you don't have to close both.
  • Inventory the mail servers you forgot you had. Exim often runs on legacy, unowned hosts — exactly the assets that survive an n-day window unpatched because no one is watching them.
  • Assume the n-day window is shrinking. Treat “critical, unauthenticated, network-reachable” as same-week work, not same-month. Set patch SLAs for a world where the exploit arrives alongside the disclosure, not weeks after it.

Open Questions

How far the automation generalizes is still unproven. XBOW's success was on deliberately softened targets; no one has publicly shown an LLM chaining this bug to RCE against a default, fully-mitigated production Exim. It's also unclear how much of the machine's speed came from the model itself versus XBOW's surrounding tooling and a human-tuned harness. And the disclosure-to-exploitation question for Dead.Letter itself remains open: a detection script is public, but confirmed in-the-wild exploitation has not been reported. Whether that stays true is the number worth watching.

Primary Documents

Read more