Exim’s Poisoned Record: How a Failed Patch and SQL Injection Lead to Critical Heap Overflows

A new security advisory has revealed significant cracks in the armor of Exim, one of the world’s most popular mail transfer agents. Andrew Fasano, the Cyber Lead at the National Institute of Standards and Technology (NIST), has disclosed two critical vulnerabilities in Exim version 4.99, warning that a previously patched hole was left partially open and has now led to a deeper, more dangerous system flaw.

The disclosure, sent to the Exim security team on November 22, 2025, details a chain of vulnerabilities involving SQLite integration that could allow remote attackers to corrupt system memory and potentially seize control of the server.

Fasano reports that a recent fix for CVE-2025-26794—a SQL injection vulnerability involving ETRN commands—did not go far enough.

While the original patch addressed the specific ETRN attack vector, it failed to fix the underlying “root cause” in the xtextencode() function. This function, responsible for sanitizing database keys, still fails to properly escape single quote characters (ASCII 39).

“The hints db remains injectable,” Fasano noted, highlighting that the flaw can now be exploited through a different avenue: Ratelimit Access Control Lists (ACLs). By sending a crafted email with a malicious “sender address,” an attacker can inject arbitrary SQL commands into the database.

While the SQL injection is dangerous on its own, Fasano discovered it serves as a gateway to a much more severe problem: a Heap Buffer Overflow.

This new vulnerability lies in how Exim processes the bloom_size field within its database records. The system reads this size field from the database without validation and uses it to determine array boundaries in memory.

“No validation occurs to ensure bloom_size matches the actual array size,” Fasano explained in the technical report.

By chaining the two flaws together, an attacker can use the SQL injection to plant a record with a massive, malicious bloom_size. When the system attempts to use this “poisoned” record, it writes data far past the allocated buffer, causing a heap overflow that Fasano successfully demonstrated could overwrite up to 1.5MB of memory.

While Fasano stopped short of achieving full Remote Code Execution (RCE) due to modern defenses like ASLR (Address Space Layout Randomization), he confirmed that the vulnerability allows for a “reliable crash oracle” and believes full RCE “may be possible with further work”. This flaw now is tracked as CVE-2025-67896.

The attack requires a specific “perfect storm” of configurations:

• SQLite Support: Exim must be compiled with USE_SQLITE=yes.
• Ratelimits: The configuration must use ratelimits that rely on attacker-controlled data (like $sender_address) as a key.

Configurations using the default per_addr without explicit keys are not vulnerable, as they rely on client IP addresses which cannot be manipulated via SMTP.

The report recommends two new CVE assignments to track these distinct issues. For remediation, Fasano advised the Exim team to implement strict validation for database records and to fix the string escaping logic in xtextencode—or better yet, migrate entirely to parameterized queries to eliminate SQL injection risks permanently.

Administrators running Exim 4.99 with SQLite integrations should upgrade to the latest version as soon as possible.

Related Posts:

• PoC Code Available for Critical SQLite Vulnerability (CVE-2025-6965)
• Google’s Big Sleep AI Foils Live Zero-Day Exploit in SQLite (CVE-2025-6965)
• CVE-2025-30232: Use-After-Free Vulnerability in Exim Exposes Systems to Privilege Escalation
• CVE-2023-42115: Critical Exim Bug Exposes Email Servers to Remote Attacks
• Exim Mail Transfer Agent Vulnerable to Remote SQL Injection (CVE-2025-26794), PoC Published