Exim ships 4.100.1 security patch covering four vulnerabilities
Three of the four flaws in this update have no workaround, so upgrading is the only real option for the ubiquitous Linux mail server.
Exim maintainers released Exim 4.100.1 today, a security-focused patch fixing four issues that span heap corruption, a use-after-free bug, a stack-data leak, and SMTP smuggling. It's only the second security fix since the general Exim 4.100 drop landed on 2026-08-20, roughly a month earlier.
It's worth a moment of context here. Exim is one of the most widely deployed mail transfer agents on the Internet, turning up on Linux mail servers and inside cloud infrastructure in large numbers. A heap-corruption bug in the way it handles inbound connections is not something you want to shrug off.
Now, an aside about the CVE numbering. The Exim Project isn't using the traditional MITRE CVE program for this release. Instead the issues are tracked under GCVE, its own Global CVE Allocation System, handed out by its Numbering Authority (GNA 25). You'll see identifiers like GCVE-25-2026-09-50-1 rather than a clean CVE-XXXX-YYYY. It works fine, though mapping those back to standard CVEs may take an extra click or two.
Two of the four carry real attribution, which is a bit unusual for Exim. Both the Proxy Protocol v2 stack leak and the SMTP smuggling flaw went to McCaulay Hudson of watchTowr, the man behind the mast1c0re exploit chain against the PS4 and PS5, who markets himself as "Master of Pwn." The other two issues get Exim's usual deadpan credit line instead: "The unnamed and uncredited authors whose works were ingested as the training corpus." That's a tongue-in-cheek jab at AI training datasets, hinting the bugs came from scraped web data fed into models rather than a named human reporter. Fair play.
The four flaws
The headline concern is the Proxy Protocol v1 bug (GCVE-25-2026-09-50-1). A remote attacker can read up to roughly 230 bytes past the end of a heap allocation, then write a single NUL byte into that over-read space. Classic heap-corruption primitive. Depending on how the memory happens to be laid out, it could turn into remote code execution.
The catch is that you need a build configured for Proxy-Protocol v1, plus a proxy in front of Exim that's buggy or compromised to make real progress. It affects Exim 4.83 (2014) all the way through 4.100, a staggering roughly 12-year range. There's no workaround. Just upgrade.
The second High-severity issue is the Proxy Protocol v2 stack leak (GCVE-25-2026-09-55-1), reported by watchTowr. It leaks stack data out to a peer, meaning sensitive in-memory contents could end up exfiltrated. Same prerequisites as the v1 bug, namely a configured Proxy-Protocol v2 plus a proxy that's buggy or compromised, and the same wide affected range.
The GnuTLS flaw (GCVE-25-2026-09-51-1) is a use-after-free that the project scored Low. That's because it can essentially only crash a receive process, which is a denial-of-service rather than anything flashier. It also needs GnuTLS 3.6.4 or newer plus a specific non-default option, tls_early_banner_hosts, turned on. You can disable that option instead of upgrading, though upgrading does it properly.
The SMTP smuggling issue (GCVE-25-2026-09-56-1) rounds things out at Medium severity, and it's the one affecting every Exim version up to and including 4.100. The idea is a submission that differs from what the sending system logged. Exim is quick to point out, though, that it applies the same normal processing to the smuggled message as to any inbound mail, which bounds how much damage it can actually do.
Response time
The project moved fast on the watchTowr reports. First reports landed on 2026-09-08, fixes were drafted within a couple of days, and the release went public by 2026-09-18, about three weeks from report to patch. The first pair of issues took a bit longer, roughly seven weeks. Both followed what the project calls a coordinated disclosure schedule, and the speed is genuinely impressive for a volunteer-run project.
Keep in mind that the raw severity numbers overstate the real-world exposure a bit. The two High issues both depend on a configured Proxy-Protocol front-end with a compromised or buggy proxy sitting in front of Exim, which is an extra moving part you often don't have. The smuggling flaw needs a specific data-phase-rejection scenario. Still, the heap over-read and the stack leak are serious on their own, and the sheer age of the affected code is hard to dismiss.
So the recommendation is blunt. Everyone running Exim 4.83 through 4.100 should upgrade to 4.100.1. Three of the four issues have no workaround at all. Only the GnuTLS use-after-free gives you a configuration-level out by disabling tls_early_banner_hosts, though honestly it's cleaner to just update.
Head here to download the release Exim 4.100.1. Download bundles come in tar.bz2, tar.gz and tar.xz, alongside the usual HTML, PDF and PostScript docs.
