Yes. CISA added CVE-2010-4345 to its Known Exploited Vulnerabilities catalogue on 25 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Exim allows local users to gain privileges by leveraging the ability of the exim user account to specify an alternate configuration file with a directive that contains arbitrary commands.
What makes this Exim flaw exploitable in practice?
The core issue is privilege boundary failure. A local user who can run Exim with an alternate configuration file can inject directives that execute arbitrary commands in a higher-privilege context, turning a local foothold into escalation. That is why the question is not just whether the bug exists, but whether the host still permits the vulnerable execution path and whether untrusted users can reach it.
For a working assessment, confirm how Exim is deployed on the system, which users can invoke it, and whether the relevant configuration path is reachable with elevated permissions. If the service is still exposed to local users in the vulnerable pattern, treat it as an active privilege-escalation condition rather than a theoretical software defect.
When you are validating exposure, the useful question is not whether Exim is installed, but whether its privilege model still lets a non-administrative actor influence command execution through configuration handling. A system can be technically patched in some places and still remain functionally exposed through custom builds, legacy packaging, or operational exceptions.
How should teams respond if patching is delayed?
If remediation cannot happen immediately, reduce the reachable attack path before you rely on time. Tighten who can execute Exim, remove unnecessary local access to mail-handling hosts, and review any wrapper scripts, scheduled jobs, or delegated utilities that can invoke the binary in ways the original deployment did not anticipate.
Because this is a local privilege escalation issue, containment is mostly about shrinking opportunity for untrusted local execution and watching for unexpected invocation patterns. If the host has multiple users, shared administration paths, or automation that touches mail transport, assume the blast radius is larger than the mail service alone.
Zero-Day and Exploited Vulnerabilities Guide is useful here because the response pattern is the same: prioritize active exploitation signals, apply emergency mitigation where needed, and do not wait for perfect certainty before reducing exposure.
Vulnerability Management Guide helps frame the operational decision: confirm scope, prioritize remediation based on exploit evidence, and track whether the exception is shrinking or just being normalized.
What should you check for after suspected compromise?
If a host may have been affected, check for evidence that the process was used to run unexpected commands, spawn unusual child processes, or alter mail-related configuration and runtime files. On a privilege-escalation flaw, the key question is not only whether the exploit ran, but whether the elevated access was used to persist, pivot, or stage additional tooling.
Review authentication logs, sudo history, process creation data, shell histories, and any monitoring that can show an ordinary mail daemon being used as a launch point. If the host handled sensitive mail or stored credentials for adjacent systems, also treat those downstream systems as potentially exposed until proven otherwise.
MITRE ATT&CK Enterprise Matrix is relevant because privilege escalation is rarely the end state, it is a step in credential access, persistence, or lateral movement.
CISA Known Exploited Vulnerabilities Catalog matters here because confirmed exploitation changes the investigation threshold, even when a patch window is already underway.
Risk and Threat Considerations
This flaw is risky because it turns a service user and a configuration mechanism into a privilege boundary bypass. Once that boundary falls, an attacker or local insider can move from limited access to command execution with materially greater control over the host and anything reachable from it.
Failure mechanism: Exim accepts an alternate configuration file path in a way that can be combined with directives containing arbitrary commands, so a local user can induce execution in a higher-privilege context.
Impact: The outcome can be full host compromise, persistence, and follow-on access to adjacent systems, especially where the mail server shares credentials, trusts, or administrative reach with other infrastructure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1068 — Exploitation for Privilege Escalation | Maps the local escalation path and follow-on attacker activity. |
| Recommendation — Hunt for privilege-escalation use and pivot from the mail process. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | The flaw exists because privilege boundaries are too permissive for the affected path. |
| Recommendation — Restrict Exim execution paths and permissions to the minimum required. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Command execution in this issue can expose credentials and access material on the host. |
| Recommendation — Rotate any exposed credentials and remove stale authentication material. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The vulnerable service account context can be abused beyond its intended role. |
| Recommendation — Reduce service-account privilege and remove unnecessary execution rights. | ||
| CIS Controls v8 | CIS-5 — Account Management | The issue depends on local account power and uncontrolled privilege pathways. |
| Recommendation — Review local accounts and remove unnecessary execution privileges. | ||
Practitioner Guidance
What to verify: Confirm whether any non-administrative user, script, or delegated process can still invoke Exim in the vulnerable pattern. If you cannot prove that the execution path is closed, treat the host as exposed until you can.
Escalation / exception: If patching is delayed, escalate it as a live privilege-escalation exposure, not a routine backlog item. The right exception is temporary containment with an explicit expiry date, not indefinite compensating controls.
Practitioner takeaway: For a KEV-listed privilege-escalation flaw, the operational priority is to prove the attack path is closed and then look for abuse, because active exploitation makes “known issue” a live host-security problem, not just a patching task.
Related resources from NHI Mgmt Group
- Guide: Email Security Guide
- CVE-2010-4345 (Exim Privilege Escalation)
- Is CVE-2014-1812 (Microsoft Windows Group Policy Preferences Password Privilege Escalation) being exploited in the wild?
- Is CVE-2021-31201 (Microsoft Enhanced Cryptographic Provider Privilege Escalation) being exploited in the wild?
- Is CVE-2024-38107 (Microsoft Windows Power Dependency Coordinator Privilege Escalation) being exploited in the wild?