Ivanti EPMM CVE-2026-5787 → CVE-2026-6973 — Pre-Auth Certificate Impersonation Chaining to RCE in Enterprise Mobile Device Management

Background and target value. Ivanti Endpoint Manager Mobile (EPMM), formerly MobileIron Core, is one of the two dominant on-premises MDM platforms in European enterprise and public-sector environments. MDM servers are exceptionally high-value targets: they hold device enrolment certificates, configuration profiles, SCEP/NDES CA material, application distribution packages, and — in most architectures — are authorised to silently push policy updates, configurations, or wipe enrolled devices fleet-wide. A compromised EPMM server gives an attacker persistent, trusted command over every enrolled mobile device in the organisation, representing a direct path to the complete endpoint fleet. European governments and healthcare systems are among the heaviest EPMM on-premises adopters, making the EU concentration of exposed instances (est. 508) particularly significant.

CVE-2026-5787: Certificate validation failure in Sentry host registration (CVSS 9.1, CWE-295)

EPMM's architecture includes a component called Sentry — a protocol-translating reverse proxy that mediates traffic between enrolled mobile devices and corporate backend services (Exchange ActiveSync, SharePoint, etc.). The EPMM server and its registered Sentry gateways maintain mutual trust via an internal PKI: when a Sentry host onboards, EPMM verifies its identity and issues it a CA-signed certificate that subsequent API calls present for authentication.

CVE-2026-5787 is a failure in the certificate issuance verification step. The EPMM server does not adequately validate that a host requesting Sentry registration is genuinely in the pre-approved registration queue before issuing a signed certificate. An unauthenticated attacker who can reach the EPMM administrative endpoint (TCP 443) submits a crafted Sentry registration request. EPMM accepts it as legitimate and issues the attacker a valid CA-signed client certificate carrying Sentry-level trust. That certificate is the key to the second vulnerability.

CVE-2026-6973: Admin API improper input validation → OS command execution (CVSS 7.2, CWE-20)

EPMM exposes a REST API for administrative operations. One or more endpoints in the affected version range accept parameters that are passed to a server-side execution context (OS command constructor, file path handler, or template engine — the exact sink is not publicly disclosed by Ivanti) without adequate sanitisation. An actor authenticated as an administrator can supply a crafted parameter value that causes the server to execute attacker-controlled OS commands at the privilege level of the EPMM service account (typically root or a high-privilege service identity on the underlying Linux host).

Chain mechanics (step-by-step)

1. Attacker identifies internet-facing EPMM port 443 (admin/MDM API)
2. Sends crafted Sentry registration request → CVE-2026-5787
3. EPMM issues valid CA-signed client certificate (Sentry trust level)
4. Attacker presents certificate to EPMM admin REST API → authenticated as admin
5. Injects OS command payload into vulnerable admin API parameter → CVE-2026-6973
6. Arbitrary OS command execution on EPMM host as service account
Post-exploitation paths:
  ├── Extract SCEP/NDES CA private key material from EPMM keystore
  ├── Enrol attacker-controlled device to gain persistent MDM trust
  ├── Push malicious MDM profile / app to enrolled device fleet
  └── Pivot to backend services via Sentry certificate trust

The combined chain converts a nominal "requires admin authentication" RCE into a fully pre-authenticated exploit — the reason CISA listed the vulnerability in KEV with a two-day remediation deadline despite the individual CVE scores.

Exploitation context and historical precedent

At disclosure (2026-05-07), Ivanti reported "very limited exploitation" of CVE-2026-6973. CISA's simultaneous KEV listing confirms verified in-the-wild exploitation. Historical precedent for Ivanti EPMM is instructive: CVE-2023-35078 (pre-auth API access, July 2023) was exploited by APT29 and LAPSUS-adjacent actors within days of disclosure, targeting European government MDM servers. CVE-2025-0283 (January 2025) followed a similar pattern. The security community should treat "very limited" as reflecting disclosure-moment telemetry, not steady-state exploitation activity; public PoC availability will accelerate exploitation.

MITRE ATT&CK mapping

Detection opportunities

• EPMM audit log (/var/log/mi*): unexpected Sentry host registration events with unknown host_id values or registration from IP addresses outside known Sentry appliance inventory
• Syslog / process audit on the EPMM host: EPMM service account spawning unexpected child processes (sh, bash, curl, wget) or accessing non-standard file paths
• Network telemetry: outbound connections from EPMM host to non-Ivanti, non-MDM-infrastructure IPs shortly after a certificate issuance event
• EDR on EPMM host (if deployed): process ancestry anomalies under the EPMM service account
• MDM enrolment audit: new device enrolment events from unrecognised device identifiers or IPs not in the corporate mobile device fleet

Immediate defensive steps (priority order)

1. Patch now — upgrade to EPMM 12.6.1.1, 12.7.0.1, or 12.8.0.1 before 2026-05-10. Ivanti provides an in-place upgrade path; no configuration migration is required.
2. Network isolation (if patching is delayed) — remove TCP 443 on the EPMM admin interface from internet exposure immediately. Place it behind VPN with allowlisted management-network source IPs.
3. Audit Sentry registrations — in the EPMM admin console, review the registered Sentry host list. Revoke any unexpected entries. If suspicious entries are found, rotate the internal EPMM CA (this revokes all existing device certificates and requires re-enrolment — a significant operational step, but necessary if compromise is suspected).
4. Audit enrolled device certificates — compare current enrolled device list against your asset inventory baseline. Anomalous device enrolments (unknown device ID, unusual user, unexpected enrolment date) may indicate post-exploitation persistence.
5. MDM quarantine isolation — if active compromise is confirmed or strongly suspected, push an MDM quarantine compliance policy to all enrolled devices before beginning forensic investigation, to prevent attacker MDM-to-device lateral movement during the response window.