CVE-2019-10149: Exim Mail Transfer Agent (MTA) Improper Input Validation

CVE-2019-10149 is an improper input validation flaw in the Exim Mail Transfer Agent (MTA). Improper validation of the recipient address in the deliver_message() function in /src/deliver.c may lead to remote command execution. For organizations that run Exim to handle inbound or outbound mail, this matters because a successful attack can give an unauthenticated remote party the ability to run commands on the mail server itself, putting the host and any connected systems at risk.

Defenders should treat this as a high-priority issue for any exposed or internet-facing Exim instance and confirm exact impact, fixed releases, and configuration details against the vendor advisory.

How it works

The weakness is classified as CWE-78 (Improper Neutralization of Special Elements used in an OS Command). In plain terms, Exim fails to adequately validate a recipient address before that value is used in message delivery processing inside deliver_message().

An attacker who can submit a message with a crafted recipient address may cause the MTA to interpret part of that address as operating-system commands. Because mail servers commonly accept connections from the network, the attack can be remote and does not necessarily require prior authentication. The precise trigger conditions, required address format, and any version-specific behavior must be taken from the vendor advisory; do not rely on third-party write-ups alone.

Am I affected? How to find it in your systems

Exim is typically deployed as the primary MTA on Linux and Unix mail servers, mail relays, and some appliance or container images that provide SMTP service. It may listen on port 25/tcp (and sometimes submission or other ports) and is often installed via distribution packages or built from source.

• Inventory every host that provides SMTP service and identify the MTA: run the Exim version command (commonly exim -bV or equivalent), check package manager metadata, or examine process listings and configuration paths such as /etc/exim or /usr/exim.
• Compare the installed version and build options against the versions listed as vulnerable in the vendor advisory. If the advisory names specific releases or configuration flags, treat only those as in-scope until you confirm otherwise.
• Look for internet-facing or broadly reachable SMTP listeners; internal relays that accept mail from untrusted sources are also relevant.
• Telemetry signs of exploitation attempts can include unusual SMTP traffic containing anomalous recipient addresses, unexpected child processes spawned by the Exim daemon, or crash/restart events around delivery. Review mail logs, process-creation logs, and any EDR alerts for command execution originating from the Exim user. Absence of obvious logs does not prove safety; confirm patch level first.

How to remediate

Patch first. Apply the updates provided by the Exim maintainers or your operating-system vendor exactly as described in the official advisory. CISA’s required action is to apply updates per vendor instructions.

• After installing the update, restart the Exim service (or reboot if required by the package) and verify the running version again.
• If you maintain custom Exim configurations or local patches, re-validate them against the fixed code so that any work-arounds do not re-introduce the validation gap.
• As general hardening for this class of flaw, ensure Exim runs with least privilege, restrict which networks may connect to the SMTP port, and keep the MTA configuration as simple as operationally possible to reduce attack surface.

If you can't patch immediately

When immediate patching is not possible, reduce exposure with compensating controls while you schedule the update.

• Segment the mail server so that only necessary internal hosts or trusted relays can reach its SMTP port; block direct internet access if the server does not need to accept external mail.
• Place a mail gateway, reverse proxy, or WAF/IPS with virtual-patching rules in front of Exim to filter or normalize suspicious recipient addresses, understanding that signature-based controls are imperfect for this class of input-validation issue.
• If operationally feasible, temporarily disable or restrict the delivery paths that exercise the vulnerable code path, or limit Exim to local submission only until the patch is applied.
• Increase monitoring: alert on anomalous SMTP commands, unexpected process execution by the Exim user, and outbound connections initiated by the mail server. Retain relevant logs for later forensic review.

If your data may have been exposed

Actively exploited remote-command-execution vulnerabilities on mail servers can lead to full host compromise and subsequent data theft or lateral movement. Known ransomware use of this CVE is not documented, but that does not rule out other malicious activity. If you have reason to believe an Exim host was compromised, follow your incident-response process: isolate the system, preserve logs and memory if possible, rotate credentials that may have been present on the host, and examine mail queues and user data for unauthorized access. You can also run a free exposure scan of your email addresses against known breach data to check whether associated accounts appear in public breach corpora.