Is CVE-2018-2380 (SAP Customer Relationship Management (CRM) Path Traversal) being exploited in the wild?

Yes. CISA added CVE-2018-2380 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. SAP Customer Relationship Management (CRM) contains a path traversal vulnerability that allows an attacker to exploit insufficient validation of path information provided by users.

What “being exploited in the wild” means for this SAP CRM CVE

This question is not just asking whether a flaw exists, it is asking whether defenders should treat it as an active threat. For CVE-2018-2380, that changes the operational posture immediately: confirmed exploitation means exposure is no longer theoretical, and any reachable SAP CRM system should be treated as a priority review item rather than a routine backlog entry.

For practitioners, the most important distinction is between vulnerability presence and exploitation evidence. A path traversal issue can be dormant in a lab, but once it appears in CISA’s KEV catalogue and is tied to ransomware use, the burden shifts from “can this be exploited?” to “have we confirmed whether our environment is exposed, already touched, or compensating controls are actually blocking it?”

Use the Zero-Day and Exploited Vulnerabilities Guide to separate routine patch planning from active-exploitation response. The right triage model is driven by exploitability evidence, not by whether the vulnerability is old, familiar, or previously missed.

How to confirm exposure and reduce blast radius

Start with inventory, not assumptions. Identify every SAP CRM instance, any internet-facing path, and any adjacent application or integration that could reach the vulnerable component. Because path traversal abuses user-supplied path information, controls at the perimeter are helpful only if they truly inspect the relevant request path and parameters, not just generic web traffic.

Then verify whether the vendor fix or mitigation has been applied, whether any compensating control is actually in force, and whether the affected system has been exposed long enough for attacker recon. If the system is business critical, reduce blast radius while remediation is underway by tightening access paths, restricting administrative reach, and increasing request logging around the affected interface.

Use the Vulnerability Management Guide for the right prioritisation pattern, because KEV-listed issues should move ahead of ordinary severity scoring alone. Use CISA Known Exploited Vulnerabilities Catalog as the authoritative trigger for remediation urgency, and use NIST National Vulnerability Database to anchor the record and product context during internal tracking.

What to do if patching must wait, and what to check afterward

If remediation cannot happen immediately, treat the delay as a risk window that needs temporary controls, not as a reason to defer action. The practical question is whether the vulnerable function is still reachable from any untrusted network or from a less trusted internal segment. If it is, the environment should be considered at elevated exposure until the fix is in place or the path is effectively removed.

After patching or mitigation, do not stop at version confirmation. Check access and application logs for unusual traversal attempts, unexpected file access patterns, repeated 403 or 404 bursts against the affected endpoint, and any signs that an attacker used the flaw to probe the filesystem or stage later activity. Because CISA links this CVE to ransomware use, a clean patch state does not by itself prove there was no prior compromise.

Where compromise indicators exist, expand the review to nearby systems, shared credentials, service accounts, and administrative sessions that might have been exposed during the attack chain. The key decision is whether the flaw only allowed reconnaissance or whether it created a foothold that could have supported follow-on access.

Risk and Threat Considerations

Active exploitation changes the threat model from “potentially dangerous” to “operationally targeted.” Path traversal is attractive because it can bypass normal application boundaries, expose files the application should never disclose, and sometimes serve as a first step toward broader compromise, especially when the vulnerable service is trusted inside a larger enterprise environment.

Failure mechanism: Insufficient validation of user-controlled path information allows an attacker to request unintended files or directories, which can expose configuration data, internal content, or other information that should not be reachable through the application.

Impact: The immediate impact can be data exposure, but the practical security concern is broader, because exposed files may reveal credentials, internal paths, or operational details that support deeper intrusion, persistence, or ransomware staging.

Practitioner Guidance

What to prioritise: Treat any reachable SAP CRM instance as urgent until you have confirmed exposure status, applied the vendor fix or mitigation, and reviewed logs for suspicious traversal attempts. If the system is internet-facing or feeds other business systems, prioritise it ahead of lower-risk vulnerabilities that are not known to be exploited.

What to verify: Confirm the vulnerable interface is actually removed or protected, not merely believed to be patched. The most useful evidence is a combination of asset inventory, change records, request logs, and a post-remediation review showing no suspicious file access or repeated traversal probes.

Practitioner takeaway: For KEV-listed flaws, the real decision is not whether exploitation is possible, but whether you can prove the vulnerable path is closed and that no attacker already used it before the fix landed.