Is CVE-2025-4428 (Ivanti Endpoint Manager Mobile (EPMM) Code Injection) being exploited in the wild?

Yes. CISA added CVE-2025-4428 to its Known Exploited Vulnerabilities catalogue on 19 May 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 Mobile (EPMM) contains a code injection vulnerability in the API component that allows an authenticated attacker to remotely execute arbitrary code via crafted API requests.

What it means when a KEV listing confirms active exploitation

CISA’s KEV catalogue is operationally important because it is not a theoretical risk list. When a CVE appears there, the practical assumption should be that attackers already have a working path to use it somewhere in the wild, so exposure should be treated as urgent rather than speculative. For this CVE, the key question is not whether the flaw is severe on paper, but whether your environment contains the vulnerable Ivanti EPMM API surface and whether that surface is reachable from untrusted networks.

That distinction matters because code injection in an API component often becomes a fast path to broader system compromise once an authenticated request can be crafted successfully. The immediate practitioner task is therefore to confirm inventory, verify whether the product is deployed, and identify every internet-facing or partner-exposed instance before assuming that patching can wait.

CISA Known Exploited Vulnerabilities Catalog is the authoritative place to confirm the KEV status and required remediation timeline, while the CVE Program remains the canonical identifier reference for the vulnerability itself.

Why API code injection in EPMM is operationally dangerous

API-focused code injection is especially dangerous in mobile device management and enterprise management platforms because those systems often sit close to sensitive administration functions, device records, policy enforcement, and downstream credentials or tokens. If an attacker can reach the affected API and successfully inject code through crafted requests, the issue can move quickly from a single vulnerable service to full server-level compromise.

In practice, that means defenders should think in terms of blast radius, not just patch status. If the platform is used to manage mobile endpoints for executives, regulated data, or privileged users, compromise of the management plane can create a broader trust failure than a normal application bug. The most useful question is whether the vulnerable instance can be isolated, segmented, or temporarily removed from exposure while remediation proceeds.

NIST Cybersecurity Framework 2.0 supports this kind of urgency by framing the issue as a govern-identify-protect response cycle, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control vocabulary for access control, logging, and configuration management around exposed management services.

What to do if patching has to wait

If you cannot remediate immediately, the goal is to reduce reachable attack surface and increase evidence. For this class of issue, that means tightening network access to the EPMM API, reviewing administrative access paths, and validating whether compensating controls such as segmentation, allowlisting, and temporary service restriction can narrow the exposure window. You should also assume that any exposed management service may have attracted scanning already, even if you have not seen a confirmed alert.

Because the vulnerability is in an API component, log review is not optional. Check for abnormal API request patterns, new administrative actions, unexpected child processes, and any change in configuration or device-management behaviour that does not fit normal operations. If the system can authenticate via tokens, sessions, or privileged service accounts, treat those as potentially exposed until you have evidence they were not touched.

NIST Cybersecurity Framework 2.0 supports containment and recovery planning, while FIRST EPSS is useful for understanding why active exploitation signals should push this issue ahead of routine backlog work.

Risk and Threat Considerations

This vulnerability combines a management-plane exposure with confirmed exploitation, which means the main risk is not just service disruption but attacker control of a high-trust administrative system. In a platform that manages devices and policy, that can turn one compromised component into a larger enterprise access problem very quickly.

Failure mechanism: An authenticated attacker sends crafted API requests that trigger code execution in the vulnerable EPMM API component, then uses that foothold to inspect, modify, or pivot through the management environment.

Impact: The result can include administrative compromise, unauthorized configuration changes, device-management abuse, lateral movement into adjacent systems, and loss of confidence in the integrity of the mobile management plane.

Standards & Framework Alignment

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

OWASP API Security Top 10 addresses the attack and risk surface, while 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-4 — Secure Configuration of Enterprise Assets and Software	Exposed EPMM instances need hardened configuration and surface reduction.
Recommendation — Harden the EPMM deployment and remove unnecessary exposure paths.
NIST CSF 2.0	ID.AM-01 — Assets are inventoried	You must know where EPMM is deployed before deciding containment and remediation.
Recommendation — Inventory every EPMM instance and verify its exposure status.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Active exploitation makes timely remediation the core control response.
	AU-2 — Event Logging	Compromise checks depend on usable API and admin activity logs.
Recommendation — Patch or mitigate the vulnerable EPMM component without delay. Ensure API and administrative activity are logged and reviewable.
OWASP API Security Top 10	API8 — Security Misconfiguration	API code injection risk is amplified by weak exposure and hardening around the management API.
Recommendation — Restrict and harden the EPMM API to reduce exploitability.

Practitioner Guidance

What to verify: Confirm whether any Ivanti EPMM instance is deployed, whether it is internet-facing, and whether the affected API surface is reachable from locations that should not be trusted. If you cannot answer those three questions quickly, exposure triage is incomplete.

Decision rule: If the instance is reachable from the public internet or from broad partner networks, treat it as urgent remediation work, not routine maintenance. If patching is delayed, isolate the service and preserve logs before making changes so you can still assess whether exploitation occurred.

What practitioners underestimate: Management systems often hold enough authority that even a short compromise window can have outsize consequences. The right response is to verify exposure, contain access, and hunt for signs of misuse before assuming the absence of an alert means the system stayed clean.

Practitioner takeaway: For a KEV-listed API code injection flaw, exposure confirmation and containment come first, because a trusted management platform can create enterprise-scale fallout long before routine patch cycles would normally catch up.