CVE-2010-4345: Exim Privilege Escalation Vulnerability

CVE-2010-4345 is a privilege-escalation vulnerability in the Exim mail transfer agent. A local user can abuse the exim account’s ability to load an alternate configuration file that includes a directive containing arbitrary commands, thereby gaining elevated privileges on the host. Because Exim often runs with elevated rights to handle mail delivery, successful abuse can give an attacker control beyond a normal user account and matter for any environment that still runs this software.

Defenders should treat this as a local privilege-escalation issue in the mail stack. Confirm exact affected releases, fixed versions, and deployment notes against the vendor advisory before acting.

How it works

The weakness falls under CWE-264 (permissions, privileges, and access controls). Exim permits the exim user account to specify an alternate configuration file. An attacker who can already run code as that account, or who can influence how the configuration is chosen, can supply a crafted file whose directives cause the process to execute arbitrary commands with the privileges Exim holds.

In practical terms, the attacker does not need a remote network exploit for this CVE itself; they need local access that lets them leverage the alternate-config path. Once the malicious configuration is processed, commands run in the security context of the Exim process, which is commonly more privileged than an ordinary user. Specific command syntax, file paths, and exact conditions must be confirmed against the vendor advisory; do not rely on third-party write-ups alone.

Am I affected? How to find it in your systems

Exim is widely used as an MTA on Unix-like mail servers, often on Linux gateways, internal relays, and hosting platforms. Inventory every host that sends or receives mail and check whether the exim binary or package is present.

• Package and binary checks: query the package manager (for example rpm, dpkg, or equivalent) for the Exim package and record the installed version string; also locate the exim binary on disk and note its path and ownership.
• Process and service discovery: list running processes and enabled services for exim or related mail daemons; note the user account under which the daemon runs.
• Configuration review: identify the primary configuration file and any mechanisms that allow an alternate config to be specified (command-line flags, wrapper scripts, or drop-in includes). Confirm whether non-root users or the exim account can influence those paths.
• Version and advisory mapping: compare the installed version to the fixed releases named in the vendor advisory. If the advisory is unclear for your build, treat the host as needing verification until you have a definitive match.
• Telemetry and log signs: look for unexpected exim invocations that reference non-standard configuration files, sudden privilege changes or shells spawned from the exim uid, and anomalous mail-related processes. Correlate with authentication and process-creation logs. Absence of such signs does not prove safety; it only means you have not observed obvious abuse.

How to remediate

Patch first. Apply the updates provided by the Exim vendor or your operating-system distributor exactly as described in the advisory. CISA’s required action is to apply updates per vendor instructions; follow that guidance and verify the new version string after installation.

• After patching, restart the Exim service cleanly and confirm it loads only the intended configuration.
• Restrict who can run Exim with alternate configuration options; limit write access to configuration directories and any include paths.
• Run the daemon with the least privilege practical for your mail flow, and ensure the exim user cannot write to locations that affect startup or configuration selection.
• Remove or disable legacy wrapper scripts that pass arbitrary config paths if they are no longer required.
• Re-inventory after remediation so that no unpatched instances remain in forgotten containers, chroots, or secondary mail relays.

If you can't patch immediately

Until the vendor update is installed, reduce exposure with compensating controls aimed at local privilege escalation and mail-service hardening.

• Segmentation: isolate mail hosts from general user workstations and from high-value administrative networks so that local access is harder to obtain.
• Access control: tightly limit login and sudo rights on Exim servers; monitor and alert on any interactive sessions as the exim user.
• Disable or constrain the affected feature: if operationally feasible, prevent use of alternate configuration files via wrapper restrictions, mandatory access controls, or by removing unnecessary setuid/setgid bits only after confirming mail still functions—validate any such change in a test environment first.
• Virtual patching / host controls: use host-based policy (for example file-integrity monitoring on config paths, or syscall filtering) to block unexpected config loading or command execution from the Exim process. A network WAF is of limited value for a local config-based issue but can still help if the attacker’s initial foothold is web-facing.
• Heightened monitoring: alert on process creation by the exim uid, on opens of non-standard configuration paths, and on privilege-escalation indicators. Retain logs long enough for later investigation.

These steps only buy time; they do not replace the vendor patch.

If your data may have been exposed

Actively exploited privilege-escalation flaws on mail servers can lead to broader host compromise and data exposure, even when ransomware use is not documented for this CVE. If you suspect abuse, isolate the host, preserve volatile evidence, rotate credentials that may have been accessible from the system, and follow your incident-response plan. You can also run a free exposure scan of your email addresses against known breach data to see whether associated accounts appear in public breach corpora, then force password resets and enable stronger authentication where needed.