New Exim BDAT Vulnerability Exposes GnuTLS Builds to Potential Code Execution

Exim, the most widely deployed open-source mail transfer agent (MTA) in the world, has released security patches addressing a severe vulnerability in its handling of the BDAT (Binary DATA) SMTP command. The flaw specifically affects Exim builds compiled with GnuTLS — one of the two primary TLS libraries supported by the project — and can result in memory corruption and potential remote code execution on vulnerable mail servers.

Given Exim's dominant presence across internet-facing mail infrastructure, this vulnerability has significant potential blast radius. Mail administrators running GnuTLS-based Exim installations should apply patches immediately.

Understanding Exim's Role in Email Infrastructure

Exim is installed by default on many Linux distributions — notably Debian and Ubuntu — and is estimated to power millions of mail servers worldwide. Its prevalence in shared hosting environments, ISP infrastructure, and enterprise deployments makes vulnerabilities in Exim inherently high-impact.

Unlike closed commercial mail platforms, Exim is configured and compiled locally by system administrators, which means the affected GnuTLS builds are not universally deployed — but they represent a substantial portion of the installed base.

The Vulnerability: BDAT Command Handling

What Is BDAT?

BDAT (Binary DATA) is an extension to the SMTP protocol defined in RFC 3030 — part of the CHUNKING extension (SMTP service extension for transmitting large messages in binary chunks). Unlike the traditional DATA command, BDAT allows binary email content to be transmitted without the dot-stuffing escape mechanism, improving efficiency for large messages.

When an SMTP client sends:

BDAT 1234
[1234 bytes of message data]

Exim processes the specified byte count and reads the corresponding data block. The vulnerability lies in how this command interacts with the GnuTLS-based TLS layer during this data processing.

Memory Corruption Root Cause

The vulnerability introduces a memory corruption condition when Exim processes BDAT commands on TLS connections in GnuTLS-compiled builds. Specific conditions — likely involving the interaction between Exim's internal buffering, the byte count specified in the BDAT command, and how GnuTLS handles the underlying TLS record layer — can produce a corrupted memory state.

Memory corruption vulnerabilities of this type have a range of potential outcomes depending on the specific memory layout and the attacker's control over the corrupt data:

The Exim project characterizes this as a vulnerability that could enable code execution, which warrants treating it as a critical-severity finding until further exploitation research clarifies the realistic exploit path.

Why GnuTLS Specifically?

Exim supports two TLS libraries:

• GnuTLS — the GNU project's TLS implementation, commonly default in Debian-based systems
• OpenSSL — the more widely used alternative, also supported

The interaction triggering this vulnerability appears specific to how Exim integrates with the GnuTLS API for TLS record handling — a code path that differs in structure from the OpenSSL integration. Systems compiled against OpenSSL are not believed to be affected by this specific issue.

To check which TLS library your Exim build uses:

# Check Exim TLS library
exim -bV | grep "TLS"
 
# Example outputs:
# Exim version 4.97.1 ... Support for: crypteq iconv() IPv6 Perl GnuTLS ...
# Exim version 4.97.1 ... Support for: crypteq iconv() IPv6 Perl OpenSSL ...

If the output includes GnuTLS, your installation may be vulnerable and should be updated immediately.

Affected Scope

Check whether CHUNKING is advertised in your Exim configuration:

# Check if CHUNKING is enabled in Exim config
grep -i "chunking" /etc/exim4/exim4.conf.template 2>/dev/null || \
grep -i "chunking" /etc/exim/exim.conf 2>/dev/null
 
# Test what extensions your server advertises (from another host)
swaks --server mail.yourdomain.com --to test@yourdomain.com --ehlo test.example.com --quit-after EHLO 2>&1 | grep -i "CHUNKING\|BDAT"

Immediate Remediation

Step 1: Update Exim to the Patched Version

On Debian/Ubuntu systems (most common GnuTLS build scenario):

# Update package list and upgrade Exim
sudo apt update
sudo apt upgrade exim4
 
# Or target just the exim4 packages
sudo apt install --only-upgrade exim4 exim4-daemon-light exim4-config
 
# Verify installed version
exim -bV | head -3

On RHEL/CentOS/Fedora:

# Update Exim
sudo dnf update exim
 
# Verify
exim --version

On systems running Exim compiled from source:

# Download the latest patched Exim release from the official repository
# https://www.exim.org/mirrors.html
 
# After downloading and extracting:
./configure [your existing build flags]
make
sudo make install
 
# Restart Exim after installation
sudo systemctl restart exim4  # Debian/Ubuntu
sudo systemctl restart exim   # RHEL/Fedora

Step 2: Restart Exim After Patching

# Debian/Ubuntu
sudo systemctl restart exim4
sudo systemctl status exim4
 
# RHEL/CentOS
sudo systemctl restart exim
sudo systemctl status exim
 
# Verify new version is running
ps aux | grep exim
exim -bV | head -1

Step 3: Temporary Mitigation — Disable CHUNKING/BDAT

If immediate patching is not possible, consider disabling BDAT/CHUNKING support as a temporary workaround:

# Add to your Exim configuration (exim4.conf.template or exim.conf)
# Disable CHUNKING extension to prevent BDAT usage
 
# In the main configuration section, add:
chunking_advertise_hosts =
 
# This prevents Exim from advertising CHUNKING to connecting clients
# Clients that support CHUNKING will fall back to standard DATA command
 
# Reload configuration (does not require full restart)
sudo exim -C /etc/exim4/exim4.conf.template -bV
sudo systemctl reload exim4

Note: Disabling CHUNKING may affect delivery performance for large messages but does not impact message delivery correctness. Standard SMTP DATA command functionality is unaffected.

Step 4: Monitor for Exploitation Attempts

# Monitor Exim mail logs for unusual BDAT command patterns
tail -f /var/log/exim4/mainlog | grep -i "BDAT"
 
# Check for crash indicators (Exim process restarts)
journalctl -u exim4 --since "7 days ago" | grep -i "error\|crash\|segfault\|killed"
 
# Check system logs for segmentation faults in Exim
grep -i "exim" /var/log/syslog | grep -i "segfault\|sigsegv"

Historical Context: Exim Security Track Record

Exim has a significant history of high-impact security vulnerabilities:

The 2019 "WIZard" vulnerability and the 2023 zero-day series both saw rapid mass exploitation by threat actors scanning for unpatched Exim instances. The 2026 BDAT vulnerability should be treated with the same urgency.

Detection Indicators

References

• The Hacker News — New Exim BDAT Vulnerability Exposes GnuTLS Builds to Potential Code Execution
• Exim Project — Official Security Advisories
• Exim Downloads and Mirrors
• RFC 3030 — SMTP Service Extensions for Transmission of Large and Binary MIME Messages
• GnuTLS Project
• CISA — Known Exploited Vulnerabilities Catalog