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 surfaced by AI-assisted analysis at XBOW, a New York based offensive-security firm, 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. XBOW's native-code analysis platform surfaced the vulnerable code path, but a human researcher, assisted by large language models, wrote the working exploit and outpaced the autonomous system. XBOW's own takeaway was that LLMs are not yet ready to write real-world exploits unaided.
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: Surfaced by XBOW's native-code analysis platform; reported by researcher Federico Kirschbaum (XBOW).
Published: 12 May 2026, last modified 17 June 2026 (NVD).
Key takeaways
The AI did not do this alone, and the honest version of the story is the interesting one. XBOW's platform surfaced the vulnerable code path through native-code analysis, but the working exploit came from a human researcher who used LLMs as an assistant, not as the author. XBOW's stated conclusion, as reported by BleepingComputer, was that LLMs on their own are not yet ready to write exploits against real-world software. The machine narrowed the haystack. A person still pulled out the needle.
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 triage. Tools that can read native code and flag a suspicious path compress the time between a fix landing and a proof of concept circulating. The defensive answer is not to out-read 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, per XBOW's own account and the reporting around it, is a division of labor. XBOW's native-code vulnerability analysis platform surfaced the suspicious BDAT path during testing, which is the hard, tedious part of vulnerability research: reading a large native codebase and flagging the handful of places where memory lifecycle and protocol state can desynchronize (XBOW). From there, an autonomous exploitation attempt raced a human researcher, Federico Kirschbaum, who was using LLMs as an assistant. The human won. XBOW's conclusion, as reported by BleepingComputer, was that LLMs on their own are not yet ready to write exploits against real-world software.
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 bug and hands you a working exploit minutes later. It is a machine that dramatically accelerates discovery and triage, paired with a skilled human who does the weaponization. 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 the human plus machine team can turn a surfaced 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 XBOW's: 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 discovery. 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: XBOW's native-code analysis platform surfaced the flaw, but a human researcher using LLM assistance wrote the working exploit, and XBOW concluded LLMs alone are not yet ready to write real-world exploits (BleepingComputer).
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?
XBOW's native-code vulnerability analysis platform surfaced the vulnerable BDAT path, and XBOW researcher Federico Kirschbaum reported it (XBOW). The discovery is notable because it pitted an autonomous exploitation attempt against a human researcher assisted by LLMs, and the human produced the working exploit first.
Does this mean AI can now find and exploit vulnerabilities on its own?
Not on its own, at least not for weaponization. AI-assisted analysis is genuinely strong at surfacing suspicious code paths across large native codebases, which is the discovery half. Turning a surfaced flaw into a reliable exploit still took a skilled human, and XBOW concluded that LLMs alone are not yet ready to write exploits against real-world software (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.
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. Disclosure writeup describing the native-code analysis platform that surfaced the flaw and the human versus AI exploitation race.
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 on affected versions, GnuTLS versus OpenSSL, Shodan exposure count, and XBOW's conclusion on LLM exploit-writing readiness.
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.
