CVE-2025-4428

What it actually does

CVE-2025-4428 is an authenticated remote code execution vulnerability in the API component of Ivanti Endpoint Manager Mobile 12.5.0.0 and earlier. A crafted API request can cause the server to interpret attacker-controlled input as code or commands, allowing execution in the context of the EPMM application or appliance service account. Because EPMM is a mobile device management platform, successful exploitation can give an attacker access to device-management data, administrative workflows, configuration profiles, and potentially a path to modify managed-device policy or stage additional payloads.

Why it matters to the business

Compromise of an Ivanti Endpoint Manager Mobile server can disrupt mobile device management operations, expose sensitive user and device inventory data, and allow attackers to manipulate policies or administrative functions that affect many enrolled devices. The vulnerability is listed in CISA KEV, has active in-the-wild exploitation, and has a high EPSS score, so internet-exposed or weakly restricted deployments should be treated as urgent. CISA’s KEV remediation due date was 2025-06-09, meaning organizations subject to KEV timelines should already have remediated and should now focus on validation and compromise assessment.

How an attack unfolds

An attacker first obtains valid access to the Ivanti EPMM API, or in real-world activity may combine this issue with another vulnerability that bypasses authentication. The attacker identifies a reachable EPMM API endpoint and sends a specially crafted request containing data designed to be evaluated or processed unsafely by the API component. When the vulnerable server processes the request, attacker-controlled code executes on the appliance. From there, the attacker can run discovery commands, retrieve configuration and application data, create or modify accounts, deploy tools, establish persistence, and use the EPMM server as a trusted management foothold. Reported exploitation activity around Ivanti EPMM zero-days makes post-patch compromise review important even if the service has since been upgraded.

How to fix it

Upgrade Ivanti Endpoint Manager Mobile to a vendor-supported fixed version newer than 12.5.0.0, following Ivanti’s official advisory and release notes for the exact target version applicable to the deployed branch. If immediate upgrade is not possible, restrict access to EPMM administrative and API interfaces to trusted management networks or VPNs, block direct internet exposure, enforce strong authentication and MFA where supported, rotate administrative credentials and API secrets, and monitor closely for exploit attempts. Because this vulnerability is actively exploited and KEV-listed, mitigation alone should be considered temporary; patching and compromise assessment are both required.

How to confirm the fix worked

Confirm the installed EPMM version is no longer 12.5.0.0 or earlier and matches a vendor-fixed release. Validate that administrative and API endpoints are not broadly internet-accessible unless explicitly required and protected. Review change records and appliance package versions after upgrade, then restart services as required by the vendor. Use authenticated vulnerability scanning or vendor-provided validation guidance to verify remediation without sending exploit payloads. After remediation, review API access logs, authentication logs, file integrity results, and outbound network telemetry for signs of activity before the patch date and shortly after patching.

Typical attack path

1. Identify an internet-facing or internally reachable Ivanti Endpoint Manager Mobile server running 12.5.0.0 or earlier.
2. Authenticate to the API using stolen, reused, phished, or otherwise obtained credentials, or chain with an authentication-bypass issue where applicable.
3. Send crafted API requests to the vulnerable API component to trigger code execution.
4. Execute system commands under the EPMM application or appliance service context.
5. Download or stage additional tooling, web shells, scripts, or reverse-connect payloads.
6. Harvest EPMM configuration, device inventory, user data, tokens, logs, and administrative information.
7. Create persistence through new accounts, scheduled tasks, modified application files, or altered appliance configuration.
8. Use the EPMM platform’s trust position to affect managed devices or pivot deeper into the network.

How to detect it

Review historical logs from the EPMM appliance, reverse proxies, WAFs, load balancers, web server access/error logs, application/API logs, authentication/audit logs, EDR or auditd telemetry, firewall logs, proxy logs, DNS logs, and NetFlow. Look for authenticated API requests with encoded payloads, template or expression syntax, command separators, shell commands, or unusually long parameters. Correlate suspicious API requests with process-creation telemetry showing the EPMM application service spawning shells, download utilities, scripting runtimes, or archive tools. Investigate outbound connections from the EPMM server to unfamiliar IPs or domains shortly after API requests. Review for newly created administrative users, unexpected role changes, modified device policies, altered configuration profiles, unusual certificate activity, unexpected file writes in application directories, new cron jobs or systemd services, and deleted or truncated logs. Because exploitation has been reported in the wild in Ivanti EPMM zero-day activity, prioritize systems exposed to the internet or reachable by broad user populations before patching.

• /api/
• ${
• %24%7B
• Runtime.getRuntime
• ProcessBuilder
• java.lang.Runtime
• bash -c
• /bin/sh -c
• curl http
• wget http
• chmod +x
• base64 -d
• python -c
• perl -e
• nc -e
• ncat -e
• /dev/tcp/
• ;id
• ;whoami
• ;uname -a
• |id
• |whoami
• `id`
• $(id)
• /etc/cron
• /var/spool/cron
• /tmp/
• /var/tmp/
• powershell -enc
• cmd.exe /c

What your security team should do

• Treat all Ivanti EPMM 12.5.0.0 and earlier systems as high-priority remediation targets because the vulnerability is KEV-listed and actively exploited in the wild.
• Patch to a vendor-fixed EPMM release immediately; if already patched, verify the exact running version and preserve logs for retrospective investigation.
• Perform a compromise assessment on any exposed EPMM appliance, especially systems accessible from the internet before 2025-06-09.
• Restrict EPMM API and administrative access to trusted IP ranges, management networks, or VPN access paths.
• Rotate EPMM administrator passwords, API credentials, service credentials, tokens, and any secrets stored or managed by the platform if compromise cannot be ruled out.
• Review EPMM user accounts, administrator roles, device policies, configuration profiles, certificates, and recent management actions for unauthorized changes.
• Search web, API, authentication, EDR, proxy, DNS, and firewall logs for suspicious crafted API requests, unusual child processes, and unexpected outbound connections from the EPMM server.
• Implement monitoring for command-execution patterns in API requests and for application-server processes spawning shells or network utilities.
• If evidence of exploitation is found, isolate the appliance, collect forensic images and logs, rebuild from trusted media where appropriate, and follow vendor incident-response guidance.