Exim runs a majority of the internet's reachable mail servers, which is exactly why CVE-2026-45185, nicknamed Dead.Letter, is a five-alarm advisory rather than a footnote. It is a critical, unauthenticated remote code execution flaw carrying a CVSS 3.1 base score of 9.8 (NVD, CVE-2026-45185). Public internet mail surveys have put Exim's share of reachable SMTP servers above half for years, and when Dead.Letter landed a Shodan search returned nearly 3.5 million exposed Exim instances, per BleepingComputer's reporting. The flaw was found and reported by Federico Kirschbaum, head of Security Lab at XBOW, a New York based offensive-security firm (BleepingComputer; The Hacker News), and it is patched in Exim 4.99.3.
Here is the direct answer to what most operators are searching for. CVE-2026-45185 is a use-after-free in Exim's BDAT (message chunking) body parser that lets an unauthenticated attacker on the network corrupt heap memory and execute code. You are affected if you run Exim between 4.97 and 4.99.2 built against GnuTLS with STARTTLS and CHUNKING advertised, which is the default posture on Debian and Ubuntu. And no, an AI did not autonomously find and weaponize this on its own. A human found it, and a human won the race to exploit it. Federico Kirschbaum, head of Security Lab at XBOW, discovered and reported the flaw on 1 May 2026. XBOW then spent the seven-day disclosure window racing its own autonomous system against a human researcher working with an LLM assistant to see which could write the exploit first. The human researcher won, and the autonomous system reached a working exploit only against a deliberately weakened target.
This post is written for defenders. It covers the reach of the bug, the config-dependent trigger at a briefing level, and a concrete action plan: patch to 4.99.3, confirm your TLS library, and restrict plus monitor SMTP exposure. It carries no exploit walkthrough and no proof of concept. It closes with the part that will matter long after this CVE is patched, which is what the human versus AI exploitation race tells you about the attackers now probing your perimeter. Every figure below links to its primary source so any claim can be audited.
TL;DR: CVE-2026-45185 (Dead.Letter) at a glance
Severity (CVSS 3.1): 9.8 CRITICAL, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (NVD).
Class: Use-after-free, CWE-416, in the BDAT body parsing path (NVD).
Impact: Unauthenticated remote code execution. No credentials, no relay rights, no user interaction (CERT Uganda advisory).
Affected: Exim 4.97 through 4.99.2, GnuTLS-linked builds only (NVD).
Not affected: OpenSSL-linked Exim builds (BleepingComputer).
Fixed in: Exim 4.99.3, released 12 May 2026 (NVD).
Trigger condition: GnuTLS build with STARTTLS and CHUNKING advertised; a TLS close_notify mid body during a chunked transfer, then a final cleartext byte on the same TCP connection (NVD).
Workaround: None. Patching is mandatory (CERT Uganda).
Exposure: Nearly 3.5 million Exim servers reachable on the internet at disclosure, per Shodan (BleepingComputer).
Discovery: Found and reported by Federico Kirschbaum, head of Security Lab at XBOW, on 1 May 2026 (BleepingComputer; The Hacker News; XBOW).
Exploit race: During the seven-day disclosure window XBOW ran its autonomous system against a human researcher using an LLM assistant. The human won; the autonomous system got a working exploit only against a weakened target (BleepingComputer; The Hacker News).
Published: 12 May 2026, last modified 17 June 2026 (NVD).
Key takeaways
A human found it, and a human won the race to exploit it. Federico Kirschbaum, head of Security Lab at XBOW, discovered and reported the flaw on 1 May 2026 (BleepingComputer; The Hacker News). XBOW then turned the seven-day disclosure window into a deliberate experiment, tasking its autonomous system with writing the exploit end to end while a human researcher wrote one with an LLM as an assistant. The human researcher won. The autonomous system did produce a working exploit, but only against a simplified target with no ASLR and a non-PIE binary, and on a second attempt against a machine with ASLR but a binary that was still non-PIE. Both halves matter: the machine cleared a real bar, and it cleared it on a target that had been weakened for it.
The most-quoted line from this episode is one researcher's personal read, not a corporate verdict. Kirschbaum's own assessment was that he does not think "LLMs alone are quite ready to write exploits against real-world software" yet (BleepingComputer). In the same account he credited AI tools with a crucial role in helping humans understand unfamiliar code and investigate suspicious areas far faster. Treat both halves as the finding: models did not close the last mile unaided, and they measurably sped up the person who did.
This is a config-dependent 9.8, which is easy to misjudge. The same Exim binary is vulnerable or not depending on which TLS library it was linked against. GnuTLS builds are exposed, OpenSSL builds are not (BleepingComputer). Because Debian and Ubuntu ship GnuTLS-backed Exim by default, the most common Linux mail deployments sit in the blast radius.
There is no configuration escape hatch. CERT Uganda states plainly that no workaround exists and that the patch is the fix (CERT Uganda). Disabling a feature or tightening a setting does not close this. Upgrading to 4.99.3 does.
Mail infrastructure is attack surface that vulnerability scanners routinely undercount. An internet-facing MTA answering on port 25 or 465 is a pre-authentication target with a long history of critical RCEs. Reachability plus an unauthenticated code path is the whole exploit chain from an attacker's point of view, which is why external attack-surface coverage matters more than a periodic internal scan.
Patch velocity is now competing with machine-speed exploitation attempts. Autonomous systems are already being pointed at freshly reported flaws to see how quickly they can produce something that works, which compresses the time between a fix landing and a proof of concept circulating. The defensive answer is not to out-race the machines, it is to shrink your exposure window: know your Exim inventory, patch fast, and monitor the paths that cannot be turned off.
What is CVE-2026-45185?
CVE-2026-45185 is a remotely reachable use-after-free in Exim's handling of BDAT message bodies, the chunked transfer mode defined by the SMTP CHUNKING extension. The official NVD description states that Exim before 4.99.3, in certain GnuTLS configurations, has a use-after-free in the BDAT body parsing path, triggered when a client sends a TLS close_notify mid body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection, which can lead to heap corruption and arbitrary code execution by an unauthenticated network attacker (NVD).
At a briefing level, that is all a defender needs. During a TLS teardown, Exim can free an internal transfer buffer while the SMTP state machine still holds a reference to it. A byte arriving on the same connection after the TLS session closes gets written into memory that has already been released. The result is heap corruption, and heap corruption in a pre-authentication network service is the classic ingredient for code execution. This post deliberately stops there. It contains no exploitation steps and no proof of concept, because the point is to help operators close the door, not to teach anyone how to walk through it.
Two properties make Dead.Letter dangerous in practice. First, it is unauthenticated: the attacker needs only the ability to open a TLS connection and speak standard SMTP, both available to anyone who can reach the server. Second, the ingredients are default-on. STARTTLS and CHUNKING are advertised by most internet-facing Exim deployments, so no unusual configuration is required for the vulnerable path to exist (CERT Uganda).
The one property that limits it is the TLS library. The bug lives in the GnuTLS-backed TLS path. Exim builds linked against OpenSSL are not affected (BleepingComputer). That single build-time choice is the difference between a 9.8 and a non-issue, and it is why your first job is to find out which library your servers actually use.
Am I affected? A three-question triage
Work through these in order. Any server that answers "yes, GnuTLS, reachable" is a patch-now asset.
1. Is the version in range?
The vulnerable range is Exim 4.97 through 4.99.2 inclusive. The fix is 4.99.3 (NVD). Check with:
exim -bV
The banner reports the Exim version at the top. Anything from 4.97 up to and including 4.99.2 is in scope. Releases before 4.97 and 4.99.3 or later are outside the vulnerable window for this specific CVE, though older Exim carries its own long history of issues and should be updated regardless.
2. Is it built against GnuTLS?
This is the deciding question. Only GnuTLS-linked builds are vulnerable. CERT Uganda recommends confirming the TLS library linkage directly on the host (CERT Uganda):
exim -bV | grep -i tls
If the support line shows GnuTLS, the server is exposed. If it shows OpenSSL, this CVE does not apply to that binary. Do not assume uniformity across a fleet: a server rebuilt from a different repository or a container image pinned to another base can flip the answer. Debian, Ubuntu, and Debian-derived distributions ship GnuTLS-backed Exim by default, so treat those as GnuTLS until proven otherwise.
3. Is it reachable, and does it advertise CHUNKING?
An unpatched GnuTLS build is only exploitable if an attacker can reach it and negotiate the vulnerable path. Inventory anything answering SMTP on the perimeter. Asset-discovery tools can key on the combination of an Exim banner and STARTTLS support to flag candidates. One published query for locating exposed instances is product:=exim AND banner:"STARTTLS" (runZero). Internal-only relays that are not reachable from untrusted networks are lower priority than internet-facing MX hosts, but they are not zero priority: an attacker who lands inside your network will look for exactly these.
Patch priority and what mail operators do now
Dead.Letter is a straightforward triage decision. It is critical, unauthenticated, network-reachable, and has no workaround. Internet-facing GnuTLS Exim servers are the highest-priority patch in your queue this cycle.
1. Upgrade to Exim 4.99.3 or later. This is the fix and there is no substitute for it. Apply it through your distribution's package manager and restart the service, then re-run exim -bV to confirm the running binary is 4.99.3 or newer (CERT Uganda). Version 4.99.3 corrects the handling of TLS session teardown during BDAT transfers.
2. Do not wait for a configuration workaround, because there is not one. The Exim project and national CERTs are explicit that no setting neutralizes this (CERT Uganda). Any advice you see to merely disable a feature is at best a partial hardening measure, not remediation.
3. Review your GnuTLS build and TLS posture. Confirm which TLS library each MTA links against and record it in your asset inventory, so the next Exim or GnuTLS advisory is a lookup rather than a fire drill. If you maintain your own Exim packages or container images, decide deliberately which TLS backend you ship rather than inheriting it by accident.
4. Restrict and monitor SMTP exposure. Limit which hosts can reach your MTAs on 25, 465, and 587 to what mail flow actually requires. For internet-facing MX servers that must accept connections from anywhere, put ingress and egress controls around them: alert on unexpected outbound connections from a mail host, which is a strong signal of a post-exploitation foothold, and watch for anomalous process activity and crashes on the MTA, since heap-corruption exploits are rarely clean on the first attempt. Egress filtering on a mail server is one of the cheapest ways to turn a successful RCE into a contained, noisy failure rather than a quiet pivot.
5. Hunt, do not just patch. If any of these servers was internet-facing and unpatched after 12 May 2026, treat the window between disclosure and your patch as a period to review, not to assume was quiet. Check for unexpected mail-process children, new cron or systemd persistence, and outbound connections that predate your upgrade. If you find signs of compromise, a fast, scoped response engagement beats a slow internal scramble; our note on when to call in help is in Emergency Pentest After a Security Incident.
The human versus AI exploitation race, and why it matters to you
The most repeated line about Dead.Letter is that AI found it. That is close enough to make a headline and wrong enough to mislead your threat model, so it is worth getting exactly right.
What actually happened is a sequence, not a machine discovery. Federico Kirschbaum, head of Security Lab at XBOW, found the use-after-free in Exim's BDAT path and reported it on 1 May 2026 (BleepingComputer; The Hacker News). That is the hard, tedious part of vulnerability research done by a person: reading a large native codebase and finding the place where memory lifecycle and protocol state desynchronize.
The AI angle came next, and it was about weaponization rather than discovery. XBOW used the seven-day disclosure window as a deliberate experiment. Part of the team set its autonomous system, XBOW Native, to develop the exploit end to end with no human in the loop, while in parallel a human researcher developed one using an LLM as an assistant. The human researcher won the race (BleepingComputer; The Hacker News).
The result is more interesting than a scoreboard, because the machine did not come away empty-handed. XBOW Native produced a working exploit, but only against a simplified target: an Exim server with no ASLR and a non-PIE binary. On a second attempt it achieved an exploit against a machine with ASLR, though the binary was still non-PIE. Notably, it went after Exim's own allocator rather than reaching for off-the-shelf glibc allocator techniques. That is a genuine result and it is also a long way from a hardened production mail server, which is the only target that matters to you. Standard binary hardening was doing real work in that gap.
The line most often repeated from this episode also deserves its correct owner. It is the researcher's personal assessment, not a corporate verdict: Kirschbaum said he does not think "LLMs alone are quite ready to write exploits against real-world software" yet (BleepingComputer). He was equally clear about the other side of it, crediting AI tools with a crucial role in helping humans understand unfamiliar code and investigate suspicious areas far faster. XBOW's own write-up is the origin of the account, though the site rate-limits automated requests, so the trade reporting above is the citation you can actually open (XBOW; The Hacker News).
For a defender, that boundary is the whole point. The state of the art in mid 2026 is not an autonomous machine that finds a critical flaw in a large native codebase and hands you a working exploit minutes later. On this CVE the discovery was human, the fastest exploit was human, and the autonomous system needed its target weakened before it landed one at all. The practical consequence is a shorter, not instantaneous, window between a fix landing and a credible exploit existing. Your defensive job is to make that window irrelevant by patching faster than a human plus machine team can turn a known flaw into a reliable exploit against your specific deployment.
It also reframes what good offensive testing looks like. The attackers who matter are already blending machine-scale coverage with human judgment. Testing that is purely manual misses breadth; testing that is purely automated misses the exact classes, like authorization and business logic, that scanners have always fumbled. We wrote about where autonomous tooling genuinely helps and where it plateaus in Agentic Red Teaming and the 24/7 AI Attacker and benchmarked the current tools in AI Pentest Benchmark Results 2026. The short version matches what XBOW's own researcher described: the machine is a force multiplier for a skilled operator, not a replacement for one.
What this means for defenders
Dead.Letter is a clean illustration of a pattern that will repeat. A critical, unauthenticated flaw sits in a piece of internet-facing infrastructure that many organizations do not think of as an application at all, and the time from disclosure to exploit is compressed by AI-accelerated tooling on the attacker's side. Patching the specific CVE is necessary. Closing the pattern requires knowing what you expose and testing it the way real attackers now do.
Continuously map your external attack surface. MTAs, VPN concentrators, and other network services drift in and out of exposure as infrastructure changes. A once-a-year snapshot cannot keep up. Continuous external testing is how you learn that a GnuTLS Exim box got stood up before an attacker does. Our argument for cadence over calendars is in Continuous Red Teaming vs the Annual Pentest.
Test infrastructure, not just apps. Mail servers, and the network exposure around them, are validated by human-led and hybrid red teaming, where senior testers reason about reachability, protocol state, and pivot paths the way an attacker does. This is distinct from web-application testing: Stingrai's autonomous AI agent, Snipe, hunts complex web-app vulnerabilities such as IDOR, broken authorization, and business-logic flaws, while MTA and network exposure sits with human-led and hybrid engagements.
Combine human and AI coverage on purpose. The Dead.Letter story is the market telling you that the effective attacker is a human amplified by machines. Effective defense mirrors that: machine-scale breadth to find the exposed Exim box, human depth to judge whether it is actually exploitable and what it reaches. More on how we use AI in offensive work is in Using AI for Offensive Security Operations.
Feed the results into your compliance evidence. External-exposure testing and red teaming produce the artifacts your auditors ask for. Stingrai's penetration testing supports your SOC 2, ISO 27001, and PCI DSS 4.0 programs with real evidence of how your perimeter holds up. Stingrai is a CREST-accredited firm based in Canada, and our senior human pentesters lead the infrastructure work.
Stingrai combines continuous external attack-surface testing with human and AI red teaming so exposed infrastructure like a vulnerable MTA is found by your side first. See how the pieces fit on our services and PTaaS pages, or compare packages on pricing.
Frequently asked questions
What is CVE-2026-45185 in Exim, am I affected, and did an AI actually find and exploit it?
CVE-2026-45185, nicknamed Dead.Letter, is a critical use-after-free in Exim's BDAT body parser that lets an unauthenticated attacker execute code on the mail server, rated CVSS 9.8 (NVD). You are affected if you run Exim 4.97 through 4.99.2 built against GnuTLS with STARTTLS and CHUNKING advertised, which is the default on Debian and Ubuntu. No, an AI did not autonomously find and weaponize it. Federico Kirschbaum, head of Security Lab at XBOW, found and reported the flaw on 1 May 2026, and when XBOW spent the seven-day disclosure window racing its autonomous system against a human researcher using an LLM assistant, the human won. The autonomous system produced a working exploit only against a simplified target with no ASLR and a non-PIE binary, and on a second attempt against a machine with ASLR but a still non-PIE binary (BleepingComputer; The Hacker News).
Which Exim versions are affected and which version fixes it?
Exim 4.97 through 4.99.2 are affected on GnuTLS-linked builds. The fix is Exim 4.99.3, released 12 May 2026 (NVD). Upgrade through your package manager, restart the service, and confirm with exim -bV.
Is my Exim server vulnerable if it uses OpenSSL instead of GnuTLS?
No. The use-after-free is in the GnuTLS-backed TLS path, and OpenSSL-linked Exim builds are not affected (BleepingComputer). Confirm which library your binary uses with exim -bV | grep -i tls. Debian and Ubuntu default to GnuTLS builds, so most stock installs on those distributions are exposed.
Is there a workaround if I cannot patch immediately?
No configuration workaround neutralizes CVE-2026-45185; upgrading to 4.99.3 is the remediation (CERT Uganda). If you truly cannot patch within hours, reduce exposure by restricting which networks can reach the MTA on SMTP ports and by adding egress filtering and monitoring, but treat that only as a stopgap until the patch lands.
How exposed is Exim on the public internet?
Exim runs a majority of the internet's reachable mail servers, with public SMTP surveys putting its share above half for years. At disclosure, a Shodan search returned nearly 3.5 million exposed Exim servers (BleepingComputer). Not all of those are GnuTLS builds in the vulnerable range, but the population at risk is very large.
How was Dead.Letter discovered?
Federico Kirschbaum, head of Security Lab at XBOW, found and reported CVE-2026-45185 on 1 May 2026 (BleepingComputer; The Hacker News). It became an AI story only after that. XBOW used the seven-day disclosure window as an experiment, setting its autonomous system to develop the exploit end to end while a human researcher developed one with an LLM as an assistant, and the human won (XBOW).
Does this mean AI can now find and exploit vulnerabilities on its own?
Not on the evidence of this case. A human found and reported CVE-2026-45185, and a human also won the exploit-writing race that XBOW ran during the disclosure window; the autonomous system landed a working exploit only after the target was simplified, first with no ASLR and a non-PIE binary, then with ASLR but a still non-PIE binary. Kirschbaum's own assessment was that he does not think "LLMs alone are quite ready to write exploits against real-world software" yet, and he credited AI tools in the same account with helping humans understand unfamiliar code and investigate suspicious areas far faster (BleepingComputer). The defensive implication is a shorter exploit window, not an instantaneous one.
How do I find every affected Exim server across my estate?
Inventory anything answering SMTP, then filter to Exim binaries in the 4.97 to 4.99.2 range that link GnuTLS. Asset-discovery tooling can key on the Exim banner plus STARTTLS support to shortlist candidates (runZero). Continuous external attack-surface testing keeps that inventory current between advisories, which is where a lot of organizations lose the race. See Continuous Red Teaming vs the Annual Pentest.
How can Stingrai help with exposed infrastructure like this?
Stingrai combines continuous external attack-surface testing with human and AI red teaming so exposed services like a vulnerable MTA are found before an attacker reaches them. Mail-server and network exposure is human-led and hybrid work by senior pentesters, while our autonomous agent Snipe focuses on complex web-application flaws. Stingrai is a CREST-accredited firm based in Canada, and our testing supports your SOC 2, ISO 27001, and PCI DSS compliance programs. Explore services or pricing.
References
NVD (NIST). CVE-2026-45185 Detail. Published 12 May 2026, last modified 17 June 2026. https://nvd.nist.gov/vuln/detail/CVE-2026-45185. Canonical record: description, CVSS 3.1 9.8 vector, CWE-416, affected 4.97 to 4.99.2, fixed 4.99.3.
BleepingComputer. New critical Exim mailer flaw allows remote code execution. May 2026. https://www.bleepingcomputer.com/news/security/new-critical-exim-mailer-flaw-allows-remote-code-execution/. Reporting that XBOW Security Lab head Federico Kirschbaum found and reported the flaw on 1 May 2026, plus affected versions, GnuTLS versus OpenSSL, the Shodan exposure count, the seven-day exploit-writing race and its outcome, and Kirschbaum's personal assessment of LLM exploit-writing readiness alongside his credit to AI tools for speeding up code comprehension.
The Hacker News. New Exim BDAT Vulnerability Exposes GnuTLS Builds to Potential Code Execution. May 2026. https://thehackernews.com/2026/05/new-exim-bdat-vulnerability-exposes.html. Independent corroboration of the discovery credit, the exploit-writing race that followed disclosure, and the limits of the autonomous system's result.
XBOW. Dead.Letter: How XBOW found an unauthenticated RCE on Exim (CVE-2026-45185). May 2026. https://xbow.com/blog/dead-letter-cve-2026-45185-xbow-found-rce-exim. The firm's own disclosure writeup and the origin of the exploit-race account. Note that xbow.com rate-limits automated requests, so the BleepingComputer and The Hacker News reports above are the reachable citations for every detail sourced to XBOW here, including the race outcome, the weakened-target caveat, and Kirschbaum's own assessment.
Uganda National CERT (CERT.UG). Exim Dead.Letter: Unauthenticated RCE via BDAT Use-After-Free in GnuTLS Builds (CVE-2026-45185). Published 14 May 2026. https://www.cert.ug/index.php/exim-deadletter-unauthenticated-rce-bdat-use-after-free-gnutls-builds-cve-2026-45185. National advisory: patch guidance, GnuTLS linkage check, statement that no configuration workaround exists.
runZero. Exim Mail vulnerability CVE-2026-45185: Find impacted assets. May 2026. https://www.runzero.com/blog/exim-mail-servers/. Asset-discovery guidance for locating exposed Exim servers via banner and STARTTLS detection.
