CISA added CVE-2026-6973 to the Known Exploited Vulnerabilities catalog (deadline 2026-05-10) on the same day Ivanti disclosed the vulnerabilities (2026-05-07). Ivanti reported "very limited exploitation in the wild" at disclosure; CISA's simultaneous KEV listing confirms verified exploitation. Only on-premises EPMM is affected; Ivanti Neurons for MDM (cloud), EPM, Sentry as a standalone product, and EPMM mobile clients are unaffected. An estimated 508 EPMM on-premises instances in the EU are internet-reachable (Censys/Shodan telemetry), concentrated in public-sector and healthcare verticals — both NIS2 Annex-I essential entities.

Fixed versions: 12.6.1.1 (12.6.x branch), 12.7.0.1 (12.7.x branch), 12.8.0.1 (12.8.x branch).

Immediate actions if patching within 24 hours is not feasible: Remove EPMM port 443 from internet exposure; place admin interface behind VPN with allowlisted management IPs; disable internet-facing Sentry registration endpoints; audit EPMM logs for unexpected Sentry host_id registration events.

Microsoft patched this in the April 2026 Patch Tuesday cycle. CISA added CVE-2026-32202 to KEV on 2026-04-28 with a deadline of 2026-05-12. Threat intelligence attributes active exploitation to APT28 (GRU Unit 26165, "Fancy Bear") targeting EU government ministries. The technique complements APT28's documented use of NTLM relay and pass-the-hash for lateral movement within government networks.

Immediate actions: Apply April 2026 Windows Patch Tuesday; block outbound TCP 445 to non-business internet destinations at the perimeter firewall; enable "Restrict NTLM" Group Policy (set to "Deny all") or migrate authentication to Kerberos-only where operationally feasible; monitor EDR for outbound 445/TCP to internet IPs from workstations.

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.