Exim CVE-2026-45185: Patch Critical STARTTLS and CHUNKING RCE Flaw

Exim has released version 4.99.3 to fix CVE-2026-45185, a critical remote code execution vulnerability in the mail transfer agent’s handling of SMTP input when GnuTLS, STARTTLS, and CHUNKING are in play.^[1] BleepingComputer reported the flaw as a remotely exploitable Exim bug and noted that successful exploitation can allow code execution on vulnerable servers.^[2]

The vulnerability is important because Exim is internet-facing infrastructure. A mail server often sits directly on port 25, accepts traffic from unknown hosts, and runs in environments where administrators may delay upgrades because mail delivery is business-critical. This is exactly the kind of service where a narrow protocol edge case can become a practical server-risk problem.

According to the Exim project’s advisory, affected systems use Exim before 4.99.3 with GnuTLS support and the relevant STARTTLS and CHUNKING conditions enabled.^[1] Administrators who cannot patch immediately can mitigate by disabling the SMTP CHUNKING extension where it is not required, but that should be treated as a temporary control rather than a replacement for the fixed release.^[1]

The bug was discovered by XBOW, whose public write-up names the issue “Dead.Letter” and describes the security impact without requiring defenders to reproduce exploit internals.^[3] The National Vulnerability Database entry also tracks CVE-2026-45185 for Exim and points to the upstream advisory and security references.^[4]

For howtofix readers, the operational pattern is familiar: internet-facing server software, protocol feature interaction, and a patch that should not wait for public exploitation. Recent server-side examples include the cPanel & WHM security update and the Apache HTTP Server HTTP/2 RCE risk. Exim deserves the same treatment: verify exposure first, then patch or reduce the protocol surface while patching is scheduled.

What mail administrators should check

After patching, verify the actual process, not only the package database. Check the Exim binary version, service restart time, listener process, and whether any container or chroot image still contains the old binary. If Exim is managed by a hosting panel or appliance, confirm whether the vendor shipped a backported fix or a full upstream version bump.

For triage, review mail logs around unusual STARTTLS negotiation failures, repeated BDAT or CHUNKING-related sessions, crashes, restarts, abnormal queue behavior, and suspicious child-process activity from the mail service account. These indicators are not proof of exploitation by themselves, but they are the right places to look before log retention rolls over. If the server also stores credentials or relays through privileged infrastructure, treat suspicious activity as a possible broader host compromise.

The safe short version is straightforward: patch Exim to 4.99.3, restart the service, verify which SMTP extensions are still advertised, and temporarily disable CHUNKING if the upgrade cannot happen immediately. Mail delivery can tolerate a controlled maintenance window better than a public-facing MTA can tolerate a known critical RCE.

References

1. Exim Project. “Exim Security Advisory: CVE-2026-45185.” Exim, May 2026. https://exim.org/static/doc/security/EXIM-Security-2026-05-01.1/
2. Sergiu Gatlan. “New critical Exim mailer flaw allows remote code execution.” BleepingComputer, May 13, 2026. https://www.bleepingcomputer.com/news/security/new-critical-exim-mailer-flaw-allows-remote-code-execution/
3. XBOW. “Dead.Letter: Critical Exim Remote Code Execution Vulnerability.” XBOW, May 2026. https://xbow.com/blog/dead-letter/
4. National Vulnerability Database. “CVE-2026-45185 Detail.” NIST NVD, accessed May 13, 2026. https://nvd.nist.gov/vuln/detail/CVE-2026-45185