Ivanti EPMM Zero-Days CVE-2026-1281 and 1340

Ivanti has disclosed two critical zero-day vulnerabilities in Endpoint Manager Mobile (EPMM) that were already being exploited before a fix existed. When a public exploit lands for an unauthenticated 9.8, the only safe assumption is that scanning has already found your server.

Because EPMM is the system that manages and pushes configuration to an organization's entire mobile fleet, a compromise here is unusually high-impact. Here are the two flaws at a glance:

CVE	Type	CVSS	Auth required	Exploited
CVE-2026-1281	Code injection (RCE)	9.8	None	Yes, pre-disclosure
CVE-2026-1340	Code injection (RCE)	9.8	None	Yes, pre-disclosure

Key takeaways

• CVE-2026-1281 and CVE-2026-1340 are unauthenticated remote-code-execution flaws in Ivanti EPMM, each rated CVSS 9.8.
• Both were exploited in the wild before disclosure, making them true zero-days, and a public PoC exploit became available shortly after.
• EPMM controls enrolled mobile devices, so a server compromise can cascade into the broader mobile estate and the data on it.
• Patch immediately and treat any unpatched, internet-reachable EPMM server as presumed compromised.
• Ivanti also released fixes for several related high-severity EPMM flaws, including another exploited bug, so apply the full update.

Why an MDM compromise is so dangerous

Endpoint Manager Mobile is mobile-device-management software. It enrolls phones and tablets, enforces policy, distributes apps, and holds credentials and configuration for the fleet it manages. An attacker who achieves remote code execution on the EPMM server is not just on one box, they are sitting at the control plane for potentially thousands of managed devices.

That position can be abused to push malicious configuration, harvest credentials, pivot into the corporate network, or quietly maintain access. It is the same reason perimeter VPNs and identity systems are prized targets: privileged position over many downstream systems.

Think about what an MDM server legitimately does, and the danger becomes obvious. It can install and remove apps on managed phones, read device inventory, enforce or relax security policy, distribute certificates, and in many configurations wipe a device remotely. An attacker with code execution on that server inherits all of those capabilities. They can push a malicious profile to every enrolled device at once, disable security controls fleet-wide, or harvest the certificates and tokens that those devices use to reach corporate email and internal apps. A single unpatched box becomes a launchpad into the entire mobile estate and, often, the internal network behind it.

This is also why "we only manage a few phones" is the wrong way to think about exposure. The value to an attacker is not the number of devices; it is the privileged foothold and the network position. A small EPMM server reachable from the internet is just as attractive as a large one, because the exploit is automated and the payoff (network access) is the same regardless of fleet size.

The exploitation timeline

Ivanti indicated that exploitation had already occurred prior to disclosure, affecting "a very limited number of customers" at the time. Critically, a public working proof-of-concept for remote code execution became available very shortly after the advisory. Once PoC code is public, the bar to exploit drops dramatically and opportunistic scanning ramps up fast.

What to do now

1. Locate every EPMM instance. Include on-premise servers and any that may be exposed to the internet for device check-in. Note the exact version.

2. Apply Ivanti's fixed EPMM release. Deploy the security update that addresses CVE-2026-1281 and CVE-2026-1340, along with the other high-severity fixes in the same batch.

3. Restrict exposure. EPMM should not be broadly reachable from the open internet. Front it with a VPN, ACLs, or a reverse proxy that limits who can reach the management endpoints.

4. Hunt for compromise. Review server logs for unexpected process execution, new accounts, web-shell artifacts, and anomalous outbound connections, especially on any server that was internet-facing before patching.

5. Rotate secrets. If you suspect compromise, rotate credentials and certificates stored or used by EPMM, and review the integrity of policies pushed to managed devices.

Use this triage order if you run EPMM and are starting now:

Priority	Action	Why it is first
1	Take internet-facing EPMM offline or behind a VPN	Stops active scanning immediately
2	Apply the fixed EPMM release	Closes both 9.8 RCE holes
3	Hunt logs for web shells and new accounts	Zero-day means you may already be hit
4	Rotate EPMM secrets and certificates	Removes any stolen credentials
5	Review pushed device policies	Catches malicious config changes

The recurring Ivanti pattern

This is not the first time Ivanti's edge and management products have been hit by exploited zero-days, and the response playbook is by now familiar. The lesson for defenders is to keep management appliances off the open internet, shrink your patch window for anything rated 9.0 or higher, and assume that pre-disclosure exploitation means you may already need to hunt rather than just patch.

The same urgency applies across edge and management gear. Our coverage of the Palo Alto GlobalProtect auth bypass and the Cisco CUCM exploited flaw shows the identical "internet-facing infrastructure under active attack" theme. If you find evidence of compromise, move straight into the containment steps from our ransomware first-hour incident response guide.

Frequently asked questions

Does this affect Ivanti Connect Secure too?

No. CVE-2026-1281 and CVE-2026-1340 specifically affect Endpoint Manager Mobile (EPMM), not Connect Secure. Ivanti has had separate advisories for its other products, so check each one you run.

We only have a handful of EPMM users. Are we a target?

Opportunistic exploitation does not care about your headcount. Automated scanners look for vulnerable EPMM endpoints regardless of organization size, and a public PoC means anyone can run the exploit. Patch on the same timeline as a large enterprise.

How do I know if I was already compromised?

Because these were exploited as zero-days, patching alone is not proof you are clean. Look for unexpected processes, new or modified files in the web application directory, unfamiliar accounts, and outbound connections to unknown hosts. When in doubt, engage incident response.

Should we re-enroll devices after patching?

If you confirm or strongly suspect server compromise, review the integrity of pushed configurations and consider rotating device credentials. Full re-enrollment may be warranted for high-sensitivity environments, but base the decision on what your investigation finds.