CVE-2025-4428: Ivanti Endpoint Manager Mobile (EPMM) Code Injection Vulnerability

CVE-2025-4428 is a code injection vulnerability in Ivanti Endpoint Manager Mobile (EPMM), specifically in its API component. An authenticated attacker can send crafted API requests to execute arbitrary code remotely. The issue stems from an insecure implementation of the Hibernate Validator open-source library (related to CVE-2025-35036). This matters because EPMM is used for mobile device management in enterprise environments; successful exploitation could give an attacker control over the management server and potentially the devices it oversees.

Public detail is limited to the CISA summary and CWE classification. Confirm all version ranges, exact attack prerequisites, and remediation steps against the current Ivanti vendor advisory before acting.

How it works

The weakness is classified as CWE-94 (Improper Control of Generation of Code, or Code Injection). In this case, the API component of EPMM does not properly constrain or sanitize input that is later processed by the Hibernate Validator library. An attacker who already holds valid authentication credentials can craft API requests that cause the server to generate and execute unintended code.

Because the flaw is in the API surface, the attacker does not need physical access or a separate foothold on the host; the malicious payload travels inside legitimate-looking API traffic. The CISA description emphasizes that the root cause is the insecure library integration rather than a separate logic error elsewhere in EPMM. No further exploit mechanics, sample payloads, or privilege-escalation paths are provided in the available facts, so defenders should treat any authenticated API interaction as potentially abusable until the vendor patch is applied.

Am I affected? How to find it in your systems

Ivanti Endpoint Manager Mobile (EPMM) is typically deployed as an on-premises or cloud-hosted mobile device management (MDM) platform that enrolls and configures smartphones, tablets, and other endpoints. Look for it in your asset inventory under names such as EPMM, MobileIron (legacy branding), or related Ivanti management consoles.

• Query configuration-management databases, software inventory tools, and network discovery scans for hosts or containers running EPMM services.
• Review installed package lists, application directories, and service banners on management servers for the EPMM product name.
• Check API gateway or reverse-proxy logs for traffic destined to EPMM API endpoints; note any unusual request patterns or authentication events from unexpected sources.
• Confirm the exact software version and build against the vendor advisory; the facts supplied here do not list affected version numbers.

Telemetry signs of exploitation would include anomalous API calls that succeed after authentication, unexpected process spawning under the EPMM service account, or outbound connections initiated by the management server. Because ransomware use is not documented for this CVE, focus first on detecting unauthorized code execution rather than looking for specific ransomware indicators.

How to remediate

The primary action is to apply the vendor-supplied update that addresses CVE-2025-4428. Follow Ivanti’s published instructions exactly; CISA also directs organizations to apply mitigations per those instructions, follow BOD 22-01 guidance if the instance is cloud-hosted, or discontinue use of the product if no mitigations are available.

• Obtain the patched release from the official Ivanti support portal and test it in a non-production environment if possible.
• After patching, re-validate that the Hibernate Validator library integration no longer accepts the previously injectable input patterns.
• Rotate any credentials that may have been used by the EPMM service accounts or API clients, and review authentication logs for signs of prior abuse.
• Harden the remaining attack surface by enforcing least-privilege API access, requiring multi-factor authentication for administrative accounts, and restricting network access to the management interfaces.

If you can't patch immediately

Until the official update can be installed, reduce exposure with compensating controls that limit who can reach the vulnerable API and what they can do once authenticated.

• Segment the EPMM server so that only authorized management subnets and jump hosts can reach its API ports; block direct internet exposure if it is not required.
• Place a web application firewall or API gateway in front of the service and enable rules that inspect and reject anomalous request bodies or parameters known to trigger code-injection patterns in similar frameworks.
• Temporarily disable or tightly restrict non-essential API endpoints if the product configuration allows it; confirm any such change against the vendor documentation.
• Increase logging and monitoring of all authenticated API activity, process creation, and outbound network connections from the EPMM host; forward these logs to a SIEM for real-time alerting.
• If the instance is cloud-hosted, apply any temporary configuration hardening or access-control lists recommended under BOD 22-01.

These measures do not eliminate the vulnerability; they only shrink the window of opportunity until the vendor patch is applied.

If your data may have been exposed

Actively exploited code-injection flaws in management platforms can lead to full compromise of the server and the mobile devices it manages, potentially exposing configuration data, credentials, or device inventories. If you suspect exploitation, isolate the affected system, preserve forensic evidence, and follow your incident-response plan. You can also run a free exposure scan of your email addresses against known breach data sets to determine whether related accounts have already appeared in public dumps.