CVE-2025-26794

What it actually does

CVE-2025-26794 is a remote SQL injection vulnerability in Exim 4.98 before 4.98.1 that is reachable when Exim is configured to use SQLite-backed hints and ETRN serialization. A remote SMTP client can place crafted input into the ETRN handling path, causing Exim to construct unsafe SQLite statements against its hints database. Successful exploitation can allow attacker-controlled SQL to run in the context of Exim’s SQLite hints store, potentially corrupting, deleting, or manipulating operational mail-transfer state. The primary technical risks are unauthorized modification of Exim metadata, mail delivery disruption, persistence of malformed hint records, and denial of service; this should not be assumed to provide operating-system command execution unless paired with another weakness or unsafe local configuration.

Why it matters to the business

Organizations running vulnerable Exim configurations may experience mail delivery delays, failed queue processing, degraded inbound or outbound mail service, and operational instability of internet-facing mail infrastructure. Because exploitation is remote over SMTP and the EPSS score is high at 0.77173, exposed systems should be treated as high-priority even though the issue is not currently listed in CISA KEV and no mature public exploit is indicated in the supplied data. The risk is concentrated in deployments that enable both SQLite hints and ETRN serialization, but internet-exposed mail servers are commonly scanned and can be probed cheaply at scale.

How an attack unfolds

An attacker first identifies an Exim SMTP service exposed to the network and determines whether ETRN is accepted or advertised. If the server is running Exim 4.98 with SQLite hints and ETRN serialization enabled, the attacker sends a crafted ETRN command containing SQL metacharacters or SQLite syntax in the ETRN argument. The vulnerable Exim code path serializes ETRN state into the SQLite hints database and incorporates attacker-controlled data into SQL without sufficient sanitization. The injected SQL executes inside the hints database, allowing the attacker to alter or corrupt Exim’s operational state. The attacker may repeat requests to test error behavior, create persistent malformed records, disrupt serialized ETRN processing, or cause mail handling failures. Evidence is most likely to appear as unusual ETRN activity, SQLite syntax errors, Exim panic/reject log entries, and unexpected changes to SQLite-backed hint database files.

How to fix it

Upgrade Exim to version 4.98.1 or later. For the supplied affected products, use the vendor-fixed versions: suitecrm Bitnami images fixed in 7.11.13; openbsd/ports fixed in commit 584d2c49addce9ca0ae67882cc16969104d7f82d; exim/exim fixed in commit bfe32b5c6ea033736a26da8421513206db9fe305. Where immediate upgrade is not possible, reduce exposure by disabling or restricting ETRN to trusted sources only, disabling ETRN serialization if it is not required, or avoiding SQLite-backed hints until the patched build is deployed. Apply SMTP ACLs to reject ETRN from untrusted networks, ensure the mail service is not unnecessarily internet-exposed, and rebuild or validate Exim hint databases if corruption is suspected. After patching, restart Exim and confirm the running process is the updated binary, not only the installed package.

How to confirm the fix worked

Confirm the installed and running Exim version is 4.98.1 or later using package inventory and Exim version output such as `exim -bV` or the operating system package manager. Review Exim configuration for SQLite hints and ETRN serialization usage, and verify ETRN is disabled or restricted if not required. Confirm vendor package versions or source commits match the fixed versions supplied for Bitnami SuiteCRM, OpenBSD ports, or upstream Exim. From a controlled test host, attempt benign ETRN requests from both trusted and untrusted networks and verify that untrusted ETRN access is rejected or safely handled without SQLite errors. Inspect Exim main, reject, and panic logs after validation for new SQLite syntax errors, database corruption messages, or unexpected ETRN processing. If SQLite hints were in use before patching, consider checking database integrity with appropriate SQLite tooling while Exim is stopped or in a safe maintenance state.

Typical attack path

1. Scan the internet or target network for hosts exposing SMTP services that identify as Exim or behave like Exim.
2. Connect to the SMTP service and issue EHLO/HELO to determine whether ETRN is available or accepted.
3. Send crafted ETRN commands containing SQL control characters or SQLite-specific syntax.
4. Trigger the vulnerable ETRN serialization path when SQLite-backed hints are enabled.
5. Execute attacker-controlled SQL against Exim’s hints database.
6. Manipulate or corrupt hint records to disrupt mail delivery, queue handling, or ETRN-related state.
7. Repeat exploitation attempts while monitoring SMTP responses for SQL errors, rejection behavior, or service instability.

How to detect it

To determine whether exploitation already occurred, review Exim logs, SMTP telemetry, and SQLite hint database artifacts for suspicious ETRN activity. Primary log sources include Exim mainlog, rejectlog, paniclog, system journal entries for the Exim service, SMTP gateway logs, packet captures, and any mail security appliances that record SMTP commands. Look for ETRN commands containing quotes, semicolons, SQL comments, UNION/SELECT, ATTACH DATABASE, PRAGMA, sqlite_master, or other SQLite keywords. Also look for repeated failed ETRN attempts from the same source, unusual ETRN use from untrusted networks, Exim panic entries, SQLite syntax errors, database locking errors, malformed database messages, or sudden mail queue/delivery anomalies after suspicious SMTP sessions. Forensic review should include SQLite-backed Exim hint files for unexpected tables, triggers, views, schema changes, abnormal timestamps, or integrity-check failures. If exploitation is suspected, preserve Exim logs, spool metadata, hint database files, and relevant network flow records before rebuilding or deleting affected hint databases.

• ETRN '
• ETRN "
• ETRN ;
• ETRN --
• ETRN /*
• ETRN */
• ETRN UNION SELECT
• ETRN SELECT
• ETRN INSERT
• ETRN UPDATE
• ETRN DELETE
• ETRN DROP
• ETRN ATTACH DATABASE
• ETRN PRAGMA
• ETRN sqlite_master
• SQLite error
• sqlite3_exec
• database disk image is malformed
• database is locked
• unrecognized token
• near ")": syntax error
• near "'": syntax error
• /var/log/exim/mainlog
• /var/log/exim/rejectlog
• /var/log/exim/paniclog
• /var/log/exim4/mainlog
• /var/log/exim4/rejectlog
• /var/log/exim4/paniclog
• /var/spool/exim/db/
• /var/spool/exim4/db/

What your security team should do

• Prioritize patching internet-facing Exim 4.98 systems because the issue is remotely reachable over SMTP and has a high EPSS probability despite not being in CISA KEV.
• Inventory mail servers and bundled appliances/images that include Exim, including Bitnami SuiteCRM deployments, OpenBSD ports builds, and source-built Exim instances.
• Identify systems using both SQLite-backed hints and ETRN serialization; treat these as the highest-risk subset.
• Upgrade to Exim 4.98.1 or the exact vendor-fixed build, then restart Exim and verify the active runtime version.
• Temporarily disable or restrict ETRN with SMTP ACLs if patching cannot be completed immediately.
• Search Exim logs and network telemetry for suspicious ETRN commands containing SQL syntax, especially before the patch date.
• Review Exim panic logs and SQLite hint databases for corruption, unexpected schema changes, or repeated SQL errors.
• Add SIEM detections for ETRN commands containing SQL metacharacters or SQLite keywords.
• Ensure mail service monitoring covers queue growth, delivery failures, and Exim process instability after remediation.