Look for public SMTP listeners that advertise both STARTTLS and CHUNKING, especially where the host runs Exim 4.97 through 4.99.2 with GnuTLS linkage. A package version that looks current is not enough if the running binary has not been verified against the patched code path.
What the exposed surface usually looks like
An Exim deployment is most suspect when the service is openly reachable on SMTP and its banner or handshake behaviour matches the vulnerable execution path, not just the package label. Public listeners that offer both STARTTLS and CHUNKING are the practical clue because they show the host is exercising the protocol features involved in the affected code path, and the patch status still needs confirmation from the running binary.
The key judgement is to separate exposure from inventory hygiene. A host can report a modern package version while still running an older or unverified binary, or while the distribution backport does not cover the exact build in service. That is why banner checks, package metadata, and binary verification all matter together.
In practice, look for systems that answer as Exim 4.97 through 4.99.2, especially where GnuTLS is linked in and the SMTP service is externally reachable. The combination does not prove compromise, but it does indicate the deployment is close enough to the affected behaviour to warrant immediate validation.
Why version checks alone are not enough
Package management often creates a false sense of safety. If the host shows a patched package but the daemon was not restarted, the binary was replaced manually, or the vendor package was rebuilt differently from the running service, the real attack surface can remain unchanged.
That is why the operational question is not “what version does the package manager report?” but “what binary is actually serving SMTP traffic right now?” For this class of issue, the running process and its linked libraries are more meaningful than a static inventory record.
When Exim is exposed on the public Internet, the safest assumption is that attackers can rapidly test the feature set by probing protocol responses. If the banner, TLS negotiation, and CHUNKING support line up with the vulnerable range, treat the host as exposed until binary-level evidence proves otherwise.
What to verify before you assume the host is safe
Check the service banner, the negotiated SMTP extensions, the installed package record, and the running process path. If those four checks do not agree, the deployment should be treated as uncertain rather than cleared.
- Confirm the live daemon version from the running process, not only from the package database.
- Verify whether the host advertises STARTTLS and CHUNKING on the public listener.
- Check whether GnuTLS is part of the active build or linkage chain.
- Confirm the patched code path is actually loaded after any update or restart.
When those checks conflict, the right assumption is that exposure may still exist. In other words, a clean inventory entry is evidence of intent to patch, not proof that the vulnerable path is gone.
Risk and Threat Considerations
Public SMTP services are attractive because they are Internet-facing, routinely probed, and often left with partial patch evidence that looks reassuring on paper. If the live Exim binary still matches the affected feature set, an attacker does not need a full compromise to start testing the edge conditions that can lead to code execution or service impact.
Failure mechanism: The deployment can remain exposed when the package version is current but the running binary, linked libraries, or active restart state do not reflect the fixed code path, leaving the vulnerable SMTP behaviour reachable.
Impact: The result is continued exposure to exploitation attempts against a mail gateway that may sit at a high-trust network boundary, with consequences that can include service disruption, mailbox abuse, or follow-on compromise of adjacent systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Exim exposure concerns Internet-facing service exploitation. |
| Recommendation — Hunt for public-facing Exim listeners and prioritise patch verification on externally reachable hosts. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The question is about verifying a vulnerable software deployment is actually patched. |
| Recommendation — Verify the running Exim binary matches the remediated build before closing the patch. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Exposure assessment depends on timely identification and validation of vulnerable services. |
| Recommendation — Continuously inventory exposed Exim services and confirm remediation on the live host. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | The subject is identifying and validating a known technical vulnerability in a service. |
| Recommendation — Track Exim exposure as a technical vulnerability and verify remediation evidence on the system. | ||
Practitioner Guidance
What to prioritise: Prioritise binary verification and service restart validation over ticket closure. If the host is Internet-facing and advertises the vulnerable protocol features, treat it as an active exposure until you can prove the patched binary is the one handling traffic.
What to verify: Confirm the exact executable in memory, the linked TLS library, and the negotiated SMTP extensions from the live service. If the package manager and daemon state disagree, resolve the discrepancy before declaring the asset remediated.
Practitioner takeaway: For Exim, the decisive evidence is the live daemon behaviour, not the nominal package version, because exposure can persist whenever the patched code path has not actually been put into service.