CVE-2026-6973: Ivanti EPMM RCE via Input Validation
Active exploitation confirmed in the wild. CISA added this to the KEV catalog on 2026-05-07. Federal agencies must patch by 2026-05-10.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-6973 |
| CVSS v3.x (NVD) | 7.2 (High) |
| Attack vector | Unknown (not provided in available NVD tool output) |
| Auth required | Yes — remotely authenticated user with administrative access |
| Patch status | Available — fixed in 12.6.1.1, 12.7.0.1, 12.8.0.1 (version trains) |
TL;DR - Ivanti EPMM has an improper input validation flaw enabling authenticated admin RCE. - EPMM versions before 12.6.1.1 / 12.7.0.1 / 12.8.0.1 are affected (per NVD wording). - It’s confirmed exploited in the wild (CISA KEV)—treat as urgent and patch immediately.
Vulnerability at a glance (what matters operationally)
CVE-2026-6973 is an Improper Input Validation vulnerability in Ivanti Endpoint Manager Mobile (EPMM) that can allow a remotely authenticated user with administrative access to achieve remote code execution (RCE). The immediate “so what” for defenders is that this is not a theoretical issue: CISA has added it to the Known Exploited Vulnerabilities (KEV) catalog, which means exploitation has been observed in real incidents.
Because exploitation requires an authenticated admin context (per NVD’s description), your priority should be twofold: (1) patch quickly, and (2) assume credential/session compromise is part of the attack chain. In other words, even if you believe admin access is “rare,” focus on how attackers could obtain it (password reuse, weak MFA, SSO misconfig, stolen cookies/sessions, phishing, or adjacent compromises) and treat suspicious admin behavior as a potential precursor to RCE.
What is this vulnerability?
Per NVD, CVE-2026-6973 is an improper input validation issue in Ivanti EPMM that allows RCE to a remotely authenticated user with administrative access. “Improper input validation” is a broad class: it often shows up as command injection, unsafe deserialization, template injection, or untrusted input reaching an interpreter. However, the specific vulnerable endpoint/component is not available in the provided primary-source outputs because the Ivanti advisory body content could not be retrieved (it appears gated behind a client-rendered portal).
Defenders should assume that if an attacker reaches the vulnerable code path with admin privileges, the impact is full compromise of the EPMM application/appliance context. That can translate into access to device management capabilities, managed device inventory, configuration profiles, certificates/tokens, and potentially downstream identity or network access depending on how EPMM is integrated in your environment. Even if the vulnerability “only” yields execution within the EPMM environment, that’s typically sufficient to pivot into broader enterprise control planes.
Technical Notes (what we can and cannot validate)
The NVD tool output provides: impact (RCE), access requirement (authenticated + admin), and fixed versions. It does not provide the CVSS vector string or a vendor-authored technical write-up in the accessible content. In the absence of validated exploit mechanics, defenders should assume exploitation may look like post-auth administrative web requests followed by unexpected process execution or system modifications on the EPMM host.
Who is affected (and fixed versions)
According to the NVD description, affected products are Ivanti Endpoint Manager Mobile (EPMM) versions before the following fixed releases:
- 12.6.1.1 (fixed in this 12.6 train)
- 12.7.0.1 (fixed in this 12.7 train)
- 12.8.0.1 (fixed in this 12.8 train)
This “before versions X, Y, and Z” phrasing is commonly used to indicate that any release earlier than the listed fixed version within that major/minor train is affected. If you’re on 12.6.x and your version is < 12.6.1.1, you should treat it as vulnerable; similarly for 12.7.x < 12.7.0.1 and 12.8.x < 12.8.0.1.
In practice, many environments don’t track EPMM versioning with enough precision. If you cannot immediately confirm your version/build, assume exposure until you can prove you are on 12.6.1.1+, 12.7.0.1+, or 12.8.0.1+. Also remember that test/staging systems and DR instances are frequently forgotten—and can become an attacker’s easiest foothold into management infrastructure.
Technical Notes (version verification)
Because the vendor advisory content wasn’t accessible in the provided sources, the exact “click path” for identifying the version in the UI isn’t validated here. Defenders should use their standard EPMM admin console “About/Version” page (or appliance package/version reporting) and record:
- Product: Ivanti Endpoint Manager Mobile (EPMM)
- Version/build number
- Patch level (if shown)
- Management URL(s) and exposure (internet-facing vs internal)
If you maintain a CMDB, update the record and tag the asset as KEV-exploited until patched.
CVSS score breakdown (what we know, and what’s missing)
NVD lists a CVSS v3.x base score of 7.2 (High) for CVE-2026-6973. That aligns with “serious impact” but not necessarily worst-case “unauthenticated wormable” risk. However, the CVSS vector string is not provided in the available NVD tool output, so we cannot authoritatively state whether the attack vector is network/adjacent/local, whether user interaction is required, or the exact CIA impacts used to compute 7.2.
Operationally, the fact that CISA KEV lists it as exploited should outweigh CVSS debates. CVSS is helpful for relative scoring, but known exploitation is a stronger driver of real-world priority. Treat this as urgent, especially if EPMM is reachable from untrusted networks or if admin authentication is tied to SSO where compromise of an identity provider could cascade into EPMM admin sessions.
A final point: because exploitation requires an authenticated admin context (per NVD), your compensating controls should focus on hardening admin access paths: MFA enforcement, restricting admin interfaces to management networks/VPN, and monitoring for anomalous admin behavior.
Exploitation status (in the wild, PoC availability)
Exploitation in the wild: Confirmed. CISA KEV indicates CVE-2026-6973 is known to be exploited, added on 2026-05-07, with a remediation due date of 2026-05-10 for U.S. federal agencies under the KEV program. That is the strongest public signal available that adversaries are actively using this flaw.
Public proof-of-concept (PoC): Unknown. The provided sources do not include links to PoC code or exploit write-ups, and we cannot confirm the existence of public exploit material without additional verifiable references. Defenders should assume that even if no PoC is public, capable threat actors can weaponize this class quickly, especially once patches are published and diffed.
Two practical implications follow: first, patching must be treated as time-sensitive even if your environment isn’t directly internet-exposed. Second, incident responders should consider hunting for signs of admin account compromise and post-auth exploitation rather than waiting for an IDS signature tied to a specific endpoint/path.
How to detect it (practitioner guidance)
Detection is challenging without vendor-provided technical indicators (specific URL paths, parameters, or process names) in the accessible advisory content. Still, you can build meaningful coverage by focusing on behavioral indicators consistent with “authenticated admin leads to RCE” on a web-managed appliance:
1) Admin console anomalies: Look for unusual login times, new admin users/role changes, repeated failed logins followed by success, or logins from new geographies/IP ranges. Because the attacker must be authenticated with admin access, account telemetry is often your earliest warning.
2) Post-auth exploitation behavior: Once an attacker has admin capability, exploitation may manifest as configuration exports, changes in device policies, new integrations, or unexpected “maintenance” actions. Follow that with host-level anomalies: unexpected child processes from the application server, suspicious outbound connections, new cron jobs, or file modifications in web/app directories.
If you can’t get host telemetry from the EPMM system, compensate with network telemetry: outbound connections from the EPMM host to unusual destinations, unexpected DNS lookups, or connections to known command-and-control patterns. Also consider placing EPMM behind a reverse proxy/WAF that logs full request metadata for the admin interface.
Technical Notes (detection queries & patterns you can deploy now)
Because the precise vulnerable request pattern is unknown, use a two-layer approach: (a) admin authentication monitoring, and (b) suspicious process/network behavior from the EPMM host.
1) Web/proxy log pattern: suspicious admin endpoints + atypical user agents If your EPMM admin traffic traverses a reverse proxy, flag admin sessions with automation-like user agents or abnormal request bursts:
index=proxy OR index=web
host=<EPMM_PROXY_HOST>
( uri_path="*/admin*" OR uri_path="*/console*" OR uri_path="*/api/*" )
| stats count, values(user_agent) as uas, dc(uri_path) as unique_paths by src_ip, user, status
| where count > 200 OR match(mvjoin(uas,";"), "(?i)curl|python-requests|wget|powershell|go-http-client")
2) Auth log pattern: admin logins from new IPs If your IdP logs are available (SSO), hunt for EPMM-admin role users authenticating from new IPs:
index=idp
app="Ivanti EPMM" OR relying_party="EPMM" OR service="EPMM"
| stats earliest(_time) as first_seen latest(_time) as last_seen values(src_ip) as ips by user
| eventstats dc(ips) as ip_count by user
| where ip_count > 3
3) Network signature (generic): new outbound from EPMM Until a specific IOC is available, alert on EPMM initiating new outbound connections to the internet (especially if historically it should not):
DeviceNetworkEvents
| where DeviceName =~ "EPMM01" // adjust
| where InitiatingProcessAccountName !in ("known_service_account1","known_service_account2")
| summarize count(), dcount(RemoteUrl), make_set(RemotePort) by bin(TimeGenerated, 1h), RemoteIP, RemoteUrl
| where dcount_RemoteUrl > 5 or count_ > 50
Assumption note: these are behavioral detections, not exploit-specific signatures. In the absence of validated exploit endpoints/parameters, defenders should prioritize high-signal administrative and egress anomalies and tighten allowlists.
Mitigation and patching (what to do next)
The primary mitigation is to upgrade EPMM to a fixed release. Per NVD, CVE-2026-6973 is fixed in:
- 12.6.1.1
- 12.7.0.1
- 12.8.0.1
Select the fixed version appropriate to your current train and Ivanti’s supported upgrade paths. If you are on an older major/minor train not covered by these fixed versions, the provided sources do not confirm whether a fix exists for that train—assume you must upgrade into a supported fixed train (and validate with Ivanti support or the official advisory).
Because exploitation is confirmed, also treat patching as only part of response. You should: - Rotate/secure admin credentials (local and IdP-linked), enforce MFA where possible, and restrict admin access by IP/VPN. - Review and approve all recent EPMM config changes (admin users, API tokens, device profiles, integrations). - Consider incident response actions (scoping and forensics) if you suspect compromise before patching, since RCE could enable persistence.
Technical Notes (concrete upgrade/workaround steps—what we can responsibly state)
The vendor advisory content was not retrievable from the provided sources, so we cannot safely publish a vendor-accurate “run this exact installer command” procedure for EPMM. Upgrade mechanics vary by deployment model and version.
What we can state concretely, based on NVD’s fixed versions, is the target state you must reach: EPMM 12.6.1.1 or later (in 12.6), 12.7.0.1 or later (in 12.7), or 12.8.0.1 or later (in 12.8). Use Ivanti’s official upgrade workflow for your platform.
If your environment uses package-based updates and you have a vendor-provided update bundle, document the exact file/version and change record. Example placeholders (do not run as-is; adapt to Ivanti’s validated procedure for your deployment):
# Example workflow scaffolding (NOT vendor-verified for EPMM):
# 1) Backup configs and database per your runbook
# 2) Upload vendor upgrade bundle for 12.8.0.1
# 3) Execute upgrade using your standard EPMM upgrade method
# 4) Reboot/validate services
Workarounds/compensating controls (assume until patched): - Restrict access to the EPMM admin interface to trusted management networks/VPN only (no direct internet exposure). - Enforce MFA for admin accounts via IdP/SSO where feasible, and disable unused admin accounts. - Monitor and restrict outbound traffic from EPMM (egress filtering). If EPMM doesn’t need general internet access, block it and allow only required destinations.
If mitigations are unavailable in your environment, CISA KEV guidance explicitly suggests discontinuing use of the product until mitigation is possible—this is extreme, but for high-risk management-plane software with confirmed exploitation, it’s a valid risk decision.
Operational checklist (patch + reduce blast radius)
| Task | Owner | Target time |
|---|---|---|
| Identify all EPMM instances (prod, staging, DR) and confirm versions | IT Ops | 24 hours |
| Upgrade to 12.6.1.1 / 12.7.0.1 / 12.8.0.1 (as applicable) | Platform owner | ASAP (KEV) |
| Audit EPMM admin accounts, MFA, SSO integrations | IAM/SecOps | 48 hours |
| Review recent EPMM config changes and tokens/keys | SecOps | 48 hours |
| Add detections for admin anomalies + EPMM egress | SOC | 72 hours |
This vulnerability sits in a device management platform, which is typically high privilege by design. Even with “admin auth required,” exploit chains often start with credential theft; treat your admin access hardening as part of remediation, not optional cleanup.
References (primary)
- NVD CVE record: https://nvd.nist.gov/vuln/detail/CVE-2026-6973
- CISA KEV entry (confirmed exploitation): https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-6973
- Ivanti advisory (referenced by NVD; content not retrievable in provided source capture): https://hub.ivanti.com/s/article/May-2026-Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-Multiple-CVEs?language=en_US
For more information on incident response planning, check out our article on what is an incident response plan. If you’re interested in learning about the differences between CVE and CVSS, visit our FAQ on the difference between CVE and CVSS.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.