Exim Mail Server Vulnerabilities: Patch CVE-2026 Now

Multiple Exim Mail Server Vulnerabilities Leads to Crash with Malicious DNS Data

Can Malicious DNS Data Really Crash Your Mail Server? Yes, and It is Happening Right Now

On April 29, 2026, the Exim development team publicly disclosed four serious security vulnerabilities affecting one of the most widely deployed mail transfer agents on the internet.

These Exim mail server vulnerabilities affect how the server processes external data, including DNS records, email headers, JSON configurations, and authentication requests. The patch, released as Exim 4.99.2, fixes all four issues.

But the real concern is this: automated scanners began probing for unpatched instances within hours of that disclosure. If your team manages Linux-based email infrastructure and has not yet upgraded, you are in a race that has already started.

This article breaks down everything you need to know, what each vulnerability does, who is most at risk, and exactly how to respond.

What is Exim and Why Does It Matter So Much Here

Before getting into the technical weeds, it helps to understand why Exim specifically draws so much attention every time a vulnerability surfaces. Exim is an open-source mail transfer agent that powers a staggering share of the world's email routing infrastructure.

It runs primarily on Unix-based systems and has been deployed for decades, which means it sits in countless server configurations across enterprises, universities, hosting providers, and small businesses.

According to a survey by Censys, roughly 4.8 million public-facing SMTP servers were running Exim as of recent data. That is not a niche tool. That is the backbone of global email for a massive portion of internet users. When Exim has a problem, the security community pays attention fast.

And this week, the problem is real.

 

A Closer Look at the Four CVEs in the 2026 Release

CVE-2026-40684: The DNS Crash You Did Not See Coming

This is the one that caught the most attention. CVE-2026-40684 Exim describes a crash triggered by malicious DNS data, specifically involving PTR records. A PTR record is a type of DNS lookup used to reverse-resolve an IP address back to a hostname.

When Exim processes a malformed PTR record on a system using the musl C library instead of the more common glibc, an octal printing error occurs. That error does not get caught cleanly. It crashes the entire connection instance.

The musl libc Exim crash is particularly concerning because musl libc is the default C library in Alpine Linux. Alpine is everywhere. It is the go-to base image for Docker containers across thousands of companies.

If you are running Exim inside a Docker container built on Alpine, CVE-2026-40684 applies to you directly. One malformed DNS record, sent deliberately or even by accident, and your mail connection drops.

The Exim DNS crash vulnerability is classified primarily as a denial-of-service risk. The attacker does not get into your system. But they can take your mail processing offline repeatedly, which for any business that depends on email communication is disruptive enough to be serious.

CVE-2026-40685: Heap Corruption Through JSON Operators

This one is more technical but arguably more dangerous in terms of long-term impact. CVE-2026-40685 involves how Exim handles JSON operators applied to invalid external input.

When a malformed or adversarial JSON configuration triggers the operator on unexpected data, it causes out-of-bounds read and write operations in memory. That leads directly to heap corruption email server behavior.

Heap corruption is not just a server crash waiting to happen. It is the kind of memory instability that, in the right circumstances, can be leveraged for further exploitation.

No confirmed remote code execution has been tied to this CVE as of the time of writing, but the presence of heap corruption always warrants serious concern among security researchers.

The Exim CVE heap corruption issue affects configurations that rely on external JSON input for filtering or routing logic, which is more common than many administrators realize.

CVE-2026-40686: Memory Leaks Hidden in Plain Email Headers

This vulnerability is sneaky in a way the others are not. CVE-2026-40686 triggers an out-of-bounds read when Exim processes email headers that contain large UTF-8 trailing characters. On its own, a single instance might not look alarming. But the problem compounds when error messages tied to that malformed header are needed for subsequent emails in the same connection session. That is when data leakage becomes possible.

In practice, the Exim UTF-8 header vulnerability could let an attacker design email headers that quietly probe what is sitting in server memory.

It is a subtle, lower-visibility attack, but in the hands of someone who knows what they are doing, it becomes a recon tool. The out-of-bounds read write exploit here does not require authentication. The attacker just needs to send a crafted email to a server that processes it.

CVE-2026-40687: SPA Authenticator Crashes and Heap Exposure

The fourth vulnerability, CVE-2026-40687, lives inside the SPA authentication driver. SPA stands for Secure Password Authentication, and it is used in Exim when connecting to external mail services, including Microsoft-based systems that rely on NTLM.

When Exim connects to a compromised or adversarial external SPA or NTLM service, the driver can be manipulated to trigger out-of-bounds memory operations. The result is either a crash of the connection instance or a leak of heap memory.

The Exim SPA authenticator vulnerability specifically raises flags for organizations running hybrid setups where Exim relays mail through Microsoft Exchange or other NTLM-capable systems.

If that external service is under an attacker's control, the attacker can use it to push malformed authentication responses back at Exim and cause real damage on the sending side.

 

Who is Most at Risk Right Now

The threat surface here is wide, but some configurations are significantly more exposed than others.

Organizations using Alpine Linux as their server or container base are directly in the crosshairs of CVE-2026-40684. The musl libc octal printing error only occurs when musl is the system's C library, which makes Alpine and musl-based Docker environments the highest-priority group for patching.

Administrators who have built routing logic using JSON operators on external input should treat CVE-2026-40685 as a near-term emergency. The Exim JSON configuration exploit path may not have a confirmed public proof-of-concept yet, but heap corruption in a production mail server is never something to leave unaddressed.

Any Exim deployment that authenticates through SPA or NTLM against external servers needs to account for CVE-2026-40687. This is especially relevant in enterprise environments that have Exim relaying to or from Microsoft infrastructure.

And broadly, any public-facing SMTP server running Exim below version 4.99.2 is a target for the Exim mail server DoS attack described in CVE-2026-40684. Automated scanners have been probing port 25 since within hours of the April 29 disclosure. That is not speculation. That is how the internet works after a CVE drops.

 

The Legacy Version Problem Nobody Wants to Talk About

There is a detail buried in the official Exim advisory that deserves far more attention than it has been getting. The Exim maintainers have confirmed that older branches of the software are no longer actively maintained. That sentence carries a heavy implication.

If you are running Exim version 4.97, 4.96, or anything older, you are not getting a patch for CVE-2026-40684 through CVE-2026-40687.

You are not getting patches for whatever comes next either. The open source mail server security flaws identified this year will remain permanently baked into your deployment unless you migrate to the current branch.

This is not a new phenomenon in open-source software. Projects focus their limited developer resources on the current release. But for system administrators who have inherited old infrastructure and never had the mandate to upgrade it, this is a serious wake-up call. Legacy Exim is now, officially, unprotected.

How to Patch Exim to 4.99.2: Step-by-Step

Check Your Current Version First

Run this in your terminal:

exim --version

or

exim -bV

If the output shows anything below 4.99.2, you need to act today.

Upgrade on Debian or Ubuntu

sudo apt update

sudo apt install exim4

Check whether your distribution's repository has already pushed 4.99.2. If not, proceed to the from-source method.

Upgrade on RHEL or CentOS

sudo yum update exim

or with DNF:

sudo dnf update exim

Again, verify the version in the repository reflects 4.99.2 before assuming you are protected.

Install from Source (Recommended for Full Control)

Download the official tarball from the Exim FTP site. Verify the checksum. Extract and compile:

tar -xzf exim-4.99.2.tar.gz

cd exim-4.99.2

make

sudo make install

Alternatively, pull directly from the official Exim Git repository using the tagged release.

After upgrading, always recheck your configuration files. The advisory specifically recommends reviewing email header handling, JSON input validation, and any SPA or NTLM authentication configurations.

 

Vulnerability Summary Table

CVE ID	Vulnerability Type	Attack Vector	Risk
CVE-2026-40684	DNS PTR crash via musl libc	Remote, no auth	Denial of Service
CVE-2026-40685	Heap corruption via JSON	Remote, crafted config	Memory Corruption
CVE-2026-40686	Out-of-bounds read via UTF-8	Remote email header	Data Leak
CVE-2026-40687	SPA/NTLM OOB crash or leak	External service	Crash or Heap Leak

 

What This Means for Email Infrastructure Security

The four vulnerabilities patched in Exim 4.99.2 tell a broader story about email server security 2026. Email infrastructure is inherently exposed.

Every SMTP server, by design, must accept incoming connections and process data from external and often unknown sources. DNS lookups, message headers, authentication handshakes, these all happen before any filtering or trust decision is made.

The SMTP server memory corruption risk in CVE-2026-40685 and the DNS PTR record attack in CVE-2026-40684 are both direct consequences of this design reality. Exim has to trust enough external data to do its job, and attackers know exactly where to look for the cracks.

What the 2026 CVE batch underscores is that network security email 2026 has to be treated as a continuous operational discipline, not a one-time setup task.

Threat actors routinely deploy automated scanners to identify unpatched mail servers. The gap between disclosure and active exploitation keeps shrinking every year.

Patching is the baseline. Beyond that, administrators should review firewall rules to restrict unnecessary access to port 25, enable rate limiting on SMTP connections, and where possible, move to managed email relay services that abstract away the raw MTA exposure.

 

Frequently Asked Questions

Q: What is the Exim mail server and who typically uses it?

Exim is an open-source mail transfer agent used on Unix-like operating systems to route, deliver, and receive email. It is popular among web hosting providers, universities, and system administrators who prefer a highly configurable option. It is estimated to run on tens of millions of servers globally.

Q: Are the 2026 Exim CVEs being actively exploited right now?

As of the time of writing, no public reports have confirmed large-scale real-world exploitation of CVE-2026-40684 through CVE-2026-40687. However, vulnerability scanning activity began quickly after the April 29 disclosure. The absence of confirmed exploitation does not mean the risk is low. It means the window to patch before exploitation happens is closing.

Q: Can I just block malicious DNS records at the network level instead of patching?

Partially. You can use a validating DNS resolver that rejects malformed records, which would reduce exposure to CVE-2026-40684. But this does not address the other three CVEs, which operate through different attack vectors like email headers, JSON configs, and SPA authentication. There is no network-level workaround that replaces upgrading to Exim 4.99.2.

Q: What happens if I cannot upgrade immediately due to production constraints?

The Exim advisory recommends isolating affected servers as much as possible while preparing for the upgrade. For CVE-2026-40687 specifically, avoiding connections to untrusted external SPA or NTLM services reduces exposure. For the DNS crash, using a trusted DNS resolver with strict validation helps. But these are temporary mitigations, not solutions.

 

Final Thoughts: Do Not Let This One Slip Through the Cracks

Every few months, a new Exim advisory lands and the security community goes through the familiar cycle. Disclosure, urgency, patching, quiet. But this time, the combination of a DNS-triggered crash on musl libc systems and a heap corruption path through JSON operators makes the Exim mail server vulnerabilities released this week particularly worth taking seriously.

The Linux mail server patch urgent message is clear. Exim 4.99.2 is available now. Older branches are confirmed unsupported. And automated scanners are already looking for anyone who has not moved yet.

If you manage email infrastructure, now is the time to run that version check. Not tomorrow morning. Right now.

 

Hoplon Infosec Insight Box: Recommendations for System Administrators

Based on the disclosed CVEs and current threat activity, here are the prioritized recommendations:

1. Run exim --version immediately on all mail servers and confirm the version number.
2. Upgrade to Exim 4.99.2 using official sources only. Verify checksums before installation.
3. Alpine Linux and musl-based Docker deployments should treat CVE-2026-40684 as critical priority.
4. Review all Exim configurations that use JSON operators on external input and sanitize validation logic.
5. If SPA or NTLM authentication connects to any external service, audit those connections before re-enabling them after upgrade.
6. Set up monitoring on port 25 activity for anomalous connection patterns that could indicate scanning or exploitation attempts.
7. Do not assume distribution package managers have already pushed 4.99.2. Verify manually.

 

Trusted Source: Official Exim Security Advisory, April 29, 2026