How do you patch or mitigate CVE-2025-4428 (Ivanti Endpoint Manager Mobile (EPMM) Code Injection)?

CISA’s required action for CVE-2025-4428 is to apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable. In practice, find every instance of Ivanti Endpoint Manager Mobile (EPMM) in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service.

What the fix for CVE-2025-4428 should look like in practice

For this Ivanti EPMM code injection issue, the practical objective is not simply to “patch” in the abstract. You need to confirm whether each EPMM deployment is reachable, apply the vendor security update or documented mitigation, and verify that the vulnerable instance is no longer externally exposed if you cannot remediate immediately.

The strongest operational sign that you are on the right track is not version matching alone, but whether the vulnerable service has been removed from the internet path or placed behind controls that actually reduce attack reach. A patch that exists but is not deployed everywhere, or a mitigation that still leaves the product broadly reachable, does not close the exposure.

Because this is a code injection class issue, treat any instance as high priority until you can show it is either fixed or taken out of service. If the vendor mitigation is the only available option, document exactly what changed, who approved it, and how you confirmed the change on every host or tenant.

How to handle exposure when patching is delayed

If you cannot apply the fix right away, your first goal is to narrow the attack surface. Remove internet-facing access wherever possible, restrict access to trusted administrative paths, and use the vendor’s mitigation instructions rather than inventing a compensating control that has not been validated for this product.

Where the product must remain in service, separate the decision to delay patching from the decision to accept exposure. That means time-boxing the exception, recording why remediation is blocked, and confirming whether the instance contains sensitive management data, credentials, or other material that would raise the impact of successful code injection.

For cloud-hosted or externally managed deployments, align the response with the applicable CISA guidance for cloud services and with the vendor’s own remediation instructions. The key question is whether you can still prevent untrusted requests from reaching the vulnerable code path while the permanent fix is being prepared.

What to check after remediation

After patching or mitigation, validate more than service availability. Confirm that the affected EPMM instance is no longer exposed to the original attack path, and review logs for signs of abnormal requests, unexpected administrative actions, new accounts, or configuration drift around the remediation window.

If the environment was reachable before the fix, assume an attacker may have used the window to establish persistence or harvest management data. That makes post-remediation review more important than a routine patch verification, especially if the product had privileged access to mobile-management functions or adjacent systems.

Where practical, compare pre- and post-change behavior for authentication, admin access, and outbound connections. A successful remediation should not only stop the vulnerable code path, it should also leave a clean operational baseline that you can explain to incident responders, auditors, or platform owners.

Risk and Threat Considerations

Code injection in a mobile device management platform is dangerous because the affected system often sits close to sensitive administration functions and may be reachable from less trusted networks. If the flaw is exposed to the internet, attackers can use it as a first foothold for deeper access rather than as a standalone nuisance.

Failure mechanism: An exposed EPMM instance may accept crafted input that reaches an unsafe execution path, allowing an attacker to run code, alter configuration, or pivot into management workflows before defenders notice.

Impact: The result can include unauthorized administrative access, service disruption, data exposure, or a broader compromise of devices and management controls that depend on the EPMM environment.

Standards & Framework Alignment

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

NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SI-16 — Memory Protection	Code injection exposure maps to controlling unsafe execution paths and exploitation impact.
	RA-5 — Vulnerability Monitoring and Scanning	This CVE requires confirming exposure and tracking vulnerable instances before remediation.
Recommendation — Harden execution paths and block unsafe code injection conditions. Scan for every EPMM instance and verify remediation status continuously.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	The issue needs rapid identification, prioritisation, patching, and verification across the estate.
Recommendation — Prioritise and verify remediation of all exposed EPMM deployments.
ISO/IEC 27001:2022	A.8.8 — Management of Technical Vulnerabilities	The subject is a disclosed vulnerability requiring controlled remediation and exception handling.
Recommendation — Track, remediate, and evidence the vulnerability treatment decision.
NIST CSF 2.0	PR.PS-01 — Configuration Management	Mitigation depends on controlled change management and secure service configuration.
Recommendation — Apply approved mitigations and preserve the secure configuration baseline.

Practitioner Guidance

What to verify: Confirm that every EPMM instance has been found, classified by exposure, and either patched, mitigated, or removed from service. A partial rollout is not enough when the vulnerable service is still reachable.

Decision rule: If the vendor fix cannot be applied cleanly, prioritize exposure removal over continued operation. Keep the product running only when you can show the remaining risk is contained and formally accepted for a short, defined period.

What practitioners underestimate: Teams often focus on the patch itself and miss the follow-up validation. For this class of issue, the important judgment is whether the vulnerable path is actually gone, not whether a change ticket says remediation happened.

Practitioner takeaway: Treat this as an exposure-management problem first and a patching problem second, because the safest outcome is a verified loss of reachability, not just a promised fix.