Is CVE-2024-13161 (Ivanti Endpoint Manager (EPM) Absolute Path Traversal) being exploited in the wild?

Yes. CISA added CVE-2024-13161 to its Known Exploited Vulnerabilities catalogue on 10 March 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Ivanti Endpoint Manager (EPM) contains an absolute path traversal vulnerability that allows a remote unauthenticated attacker to leak sensitive information.

What the KEV listing means for Ivanti EPM exposure

CISA’s addition of CVE-2024-13161 to the KEV catalogue is the clearest operational signal that the issue is not just theoretical. For defenders, the immediate question is whether Ivanti Endpoint Manager is present anywhere in the estate, whether it is internet-reachable, and whether any instance has already been exposed long enough to merit compromise review rather than routine patch scheduling.

Because the flaw is an absolute path traversal in a remote unauthenticated attack path, you should treat exposed EPM instances as sensitive until proven otherwise. A traversal issue can let an attacker pull data outside the intended application boundary, so the practical concern is not only service availability but also whether files, configuration data, or other sensitive material were readable before detection.

If you need the official tracking sources, use the CISA Known Exploited Vulnerabilities Catalog for exploitation status and the CVE Program entry for the vulnerability record itself. Those sources are the right place to confirm the identifier and current remediation guidance instead of relying on reposted summaries.

How to confirm exposure and scope the response

Start with inventory, because KEV status only matters if the product is actually deployed. Confirm where Ivanti Endpoint Manager is installed, which versioned instances are externally accessible, and whether any reverse proxies, load balancers, or perimeter rules may still leave management interfaces reachable from untrusted networks. If you cannot quickly map exposure, assume the blast radius is larger than the monitoring stack currently shows.

For a traversal issue, scope the response around what the application could read, not only what it could execute. Review the server-side file system paths, application configuration files, logs, service account material, and any locally stored connection details that an unauthenticated reader might have reached. That same mindset is why the NIST National Vulnerability Database remains useful: it helps teams correlate the vulnerability record with affected-product context and prioritisation data while they validate their own environment.

Once exposure is confirmed, look for signs of access that predate the fix window. For traversal-style flaws, that means reviewing web and application logs for suspicious request patterns, unusual file path access, error spikes, and any evidence that sensitive files were requested repeatedly or in a scripted sequence. If the product was internet-facing, assume reconnaissance may have started before public disclosure pressure made the issue obvious.

What to do if patching is delayed or compromise is suspected

The best immediate control is to reduce reachability, then reduce value. If patching cannot happen at once, restrict external access to Ivanti EPM, segment it from broad internal networks, and remove any unnecessary administrative paths until the vendor fix is in place. That is especially important when an unauthenticated bug can be exercised without credentials, because perimeter-only trust assumptions no longer hold.

If there is any credible sign of pre-patch exposure, move beyond patching and perform a compromise assessment. Check whether configuration files, stored secrets, API keys, service credentials, or other sensitive material may have been exposed through the traversal path. If those items could have been read, rotate them in the order of likely blast radius, with the most privileged or broadly reusable material first. The response pattern is similar to other actively exploited products, including the Ivanti Connect Secure exploitation 2024 incident, where exposed credentials drove the downstream risk.

Where the product holds sensitive operational data, also consider session invalidation, credential rotation, and any downstream trust relationship that could have been abused after file access. A traversal flaw often becomes a foothold for later privilege abuse if the leaked material includes tokens, config secrets, or service account details. That is why CISA KEV status should trigger both remediation and exposure review, not just a routine maintenance ticket.

Risk and Threat Considerations

The main risk is that an unauthenticated attacker can use a path traversal flaw to read sensitive data from a system that operators may still regard as internal and trusted. Once a management platform leaks configuration or credential material, the issue can shift quickly from information disclosure to broader environment compromise.

Failure mechanism: The attacker sends crafted requests that force the application to resolve file paths outside the intended directory boundary, then uses any readable output, error message, or side effect to extract files that were never meant to be exposed.

Impact: Sensitive files, secrets, and operational metadata can be disclosed, which may enable follow-on access, lateral movement, or further compromise of connected systems.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation requires rapid identification and remediation of exposed assets.
Recommendation — Prioritise exposed Ivanti EPM instances for immediate remediation and verification.
NIST CSF 2.0	RS.MI-01 — Mitigation is performed	Active exploitation calls for containment and mitigation of the vulnerable service.
	DE.CM-08 — Vulnerabilities are identified and managed	The question is about exploited vulnerability status and exposure confirmation.
Recommendation — Contain exposed EPM systems and apply the vendor fix or compensating control. Track Ivanti EPM exposure and validate remediation status across the environment.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The issue requires prompt flaw remediation and verification of vulnerable deployments.
	RA-5 — Vulnerability Monitoring and Scanning	Teams need monitoring and scanning to confirm where the affected product is deployed.
Recommendation — Patch the vulnerable Ivanti EPM systems and verify remediation completion. Scan for Ivanti EPM instances and monitor for signs of exploitation.

Practitioner Guidance

What to verify: Confirm whether any Ivanti EPM instance was internet-reachable before remediation, because that determines whether you only need patch verification or a full compromise assessment. Treat file-read flaws as potential secret exposure events until logs and file access evidence prove otherwise.

Escalation / exception: Escalate immediately if the system stored reusable credentials, connection strings, certificates, or administrative exports. In that case, patching alone is not enough, because the exposed material can outlive the vulnerable service.

Practitioner takeaway: When CISA places a vulnerability in KEV, the response question is no longer “should we patch”, it is “what may already have been read, and what downstream trust must now be assumed compromised?”