Ivanti EPMM CVE-2026-1281 and CVE-2026-1340: Unauthenticated RCE Under Mass Exploitation

On January 29, 2026, Ivanti disclosed two zero-day vulnerabilities in Endpoint Manager Mobile (EPMM): CVE-2026-1281 and CVE-2026-1340. Both carry a CVSS score of 9.8 and enable unauthenticated remote code execution on internet-exposed EPMM appliances without any user interaction. Ivanti released a fixed version (12.8) on March 18. CISA added CVE-2026-1340 to the Known Exploited Vulnerabilities catalog on April 8 with a federal remediation deadline of April 11.

The escalation pattern here is worth noting. These were not obscure vulnerabilities that sat quietly in a backlog. Exploitation was confirmed in the wild within days of disclosure. The German Federal Office for Information Security (BSI) issued a warning with severity 3/Orange — its second-highest rating — and confirmed more than 20 German organizations had been compromised. The Dutch Data Protection Authority and the Council for the Judiciary were publicly confirmed as victims. The European Commission opened an investigation into its own mobile infrastructure. For a mobile device management platform that sits at the boundary of corporate network access and employee devices, that is a significant blast radius.

Mobile Device Management systems like Ivanti EPMM are architecturally interesting to attackers for a specific reason: they combine broad organizational access with a relatively small attack surface that security teams often under-monitor. An EPMM appliance manages device configurations, certificates, credentials, VPN profiles, and application policies for an entire organization's mobile fleet. Compromise of the management plane gives an attacker a privileged view into what devices exist, where they are, and often what credentials they hold.

Most organizations expose EPMM over the internet by design — it needs to reach corporate-managed devices outside the office network. This means the vulnerability is not behind a VPN or bastion host. It is reachable from anywhere. When combined with unauthenticated exploitation, the exposure is direct: a public IP, a known software fingerprint, and a missing patch are all an attacker needs to begin the attack chain. Shodan and Censys have historically indexed thousands of Ivanti EPMM instances, making automated scanning and exploitation straightforward for organized threat actors.

The root cause documented by watchTowr and corroborated by Palo Alto Unit 42 and Horizon3.ai is a shell arithmetic expansion bug in Bash scripts used internally by EPMM. Specifically, the map-appstore-url endpoint (CVE-2026-1281) and the adjacent map-aft-store-url endpoint (CVE-2026-1340) forward attacker-controlled input into Bash arithmetic expansion ($(( ... ))). Because the shell evaluates this input as an expression, an attacker can inject commands that the appliance then executes as a privileged process.

In practice: an unauthenticated HTTP request reaches the EPMM web interface, specific parameters are passed into the vulnerable Bash script, the shell evaluates the injected payload, and the appliance runs attacker code. Observed post-exploitation activity has included web shell deployment for persistent access, reverse shell establishment, cryptominer installation, and secondary payload retrieval. Telekom Security documented mass exploitation of both CVEs, with observed payloads downloading a second-stage script (/slt) that installs persistence mechanisms. GreyNoise telemetry showed 83% of observed exploitation traffic originating from a single bulletproof hosting IP, suggesting at minimum one organized actor running automated scanning against vulnerable EPMM instances globally.

Ivanti and NCSC-NL jointly released detection scripts (Ivanti-Host-EPMM-Scan-v2-0S-2 for standard environments and Ivanti-Host-EPMM-Scan-v2-0L-2 for log-heavy deployments) updated on February 12, 2026. These scripts check for indicators of post-exploitation activity on the appliance itself, including anomalous file creation, unexpected processes, and network connections. Running these is a required first step for any organization that has not yet verified the integrity of its EPMM installation.

Beyond the vendor scripts, look for these patterns in your environment: unexpected outbound connections from the EPMM server to external IPs, new cron jobs or startup scripts added after your last known-good configuration, web shell files in EPMM web-accessible directories, and unusual log gaps or truncation (a common technique for covering exploitation traces). Ivanti noted that because threat actor tactics are still being characterized, no definitive IoC list exists — this means defenders must use behavioral detection and integrity verification rather than relying on hash or IP blocklists alone. For organizations with confirmed exposure windows before the February or March patches were applied, treat the appliance as potentially compromised and investigate accordingly, even without definitive IoC matches.

The first decision is patch versus isolate. If you are running EPMM on any version below 12.8, and the system is internet-reachable, patching to 12.8 should already be done. If patching is blocked by change control processes, network-level isolation of the EPMM management interface from public internet is the minimum required interim control — not a general recommendation, a minimum. CERT-EU, BSI, and CISA guidance all converge on: restrict access, patch, invalidate existing sessions, and preserve forensic artifacts before cleanup.

For organizations that patched in March or early April, the key remaining question is whether exploitation occurred before the patch was applied. Given that active exploitation was confirmed in January and the patch arrived in March, there is a six-week window to investigate. This is not a theoretical concern — Ivanti's own detection scripts and BSI guidance are premised on the assumption that some systems were compromised before patches were available. The correct posture is to validate appliance integrity, review session logs for anomalous device registrations or configuration changes, and confirm no persistent web shells or scheduled tasks were installed during the exposure period.

If your organization uses EPMM to distribute VPN credentials, Wi-Fi certificates, or enterprise application configurations to mobile devices, the scope of a compromise extends beyond the appliance itself. Device profiles containing sensitive credentials may have been visible to an attacker with full appliance access. Post-incident scope definition should include inventory of what EPMM was configured to distribute and an assessment of whether those credentials or certificates need to be rotated.