CVE-2026-1281: Ivanti EPMM zero-day gives attackers code execution without a login

What it is

Ivanti EPMM (formerly MobileIron Core) uses old bash scripts behind Apache RewriteMap rules to build URLs for its In-House Application Distribution feature. The script, /mi/bin/map-appstore-url, takes values from the request and later compares one of them in a bash arithmetic expression. By pointing that value at a second variable that holds a command substitution, an attacker gets bash to run the command. The request needs no login: a GET to /mifs/c/appstore/fob/... is enough.

The twin bug CVE-2026-1340 is the same flaw in a second script, /mi/bin/map-aft-store-url, behind the Android File Transfer feature (/mifs/c/aftstore/fob/...). Patch and hunt for both together.

Ivanti disclosed both as zero-days. watchTowr published a working request the next day, and exploitation went from targeted to automated within a week. EPMM holds your mobile device inventory, users, LDAP configuration and the policies pushed to every phone, so a compromised server affects more than itself.

Attackers used the access for:

• Dormant in-memory loaders (“sleeper” web shells) at /mifs/403.jsp, consistent with an access broker preparing appliances for resale (Defused).
• JSP web shells, reverse shells, the Nezha monitoring agent and other malware (Unit 42).
• Dumps of the mifs database (users, devices, LDAP server configuration, password history) and archives of /mi/files/system, downloaded and then deleted (Telekom Security).

In May, Ivanti disclosed CVE-2026-6973, an exploited flaw that needs EPMM admin credentials, and said customers who rotated credentials after a CVE-2026-1281 or CVE-2026-1340 compromise face significantly less risk from it.

Am I affected?

You’re affected if you run on-premises EPMM 12.7.0.0 or earlier (including the 12.5.1.0 and 12.6.1.0 lines) and you haven’t either:

• applied the January 2026 RPM for your branch after your last upgrade, or
• upgraded to 12.6.1.1, 12.7.0.1, 12.8.0.1 or later.

The RPM does not survive a version upgrade. If you applied it and then upgraded to another version without the fix, you are exposed again.

Not affected: Ivanti Neurons for MDM (cloud), Ivanti Endpoint Manager (EPM) and Ivanti Sentry.

NCSC-NL told all EPMM users to assume compromise and investigate. BSI, quoted by Telekom Security, said exploitation may have started as early as summer 2025, and that appliances should be treated as compromised even if they were patched on disclosure day.

What to do

1. Upgrade. Move to the newest EPMM release for your branch: 12.6.1.1, 12.7.0.1, 12.8.0.1 or later. These include the fix, so the January RPM is no longer needed. Ivanti has fixed more EPMM flaws since, so pick the newest build available, not just the minimum.

2. If you can’t upgrade tonight, apply the RPM for your branch. It needs no downtime.

• RPM 12.x.0.x for 12.5.0.x, 12.6.0.x and 12.7.0.x
• RPM 12.x.1.x for 12.5.1.0 and 12.6.1.0

Reapply it after every version upgrade until you’re on a fixed release.

3. Check for compromise, even if you patched on day one. Run Ivanti’s exploitation detection script (built with NCSC-NL) and follow Ivanti’s analysis guidance. Review your SIEM or syslog copy of the logs, not only the logs on the appliance, since attackers deleted their own files. Defused advises restarting the application servers after patching to clear any in-memory loader, since it never touches disk.

4. If you find signs of compromise:

• Don’t clean the appliance in place. Ivanti says to restore from a known-good backup or build a new EPMM and migrate to it.
• Rotate every credential the appliance held: admin accounts, the LDAP bind account, and any service or API accounts. Ivanti tied this step to lower risk from the admin-level flaw CVE-2026-6973.
• Review admin accounts, SSO and LDAP settings, the apps and policies pushed to devices, and VPN or network configuration for changes.
• Check systems reachable through Ivanti Sentry for reconnaissance and lateral movement.
• Treat the user, device and LDAP data in the database as stolen.

Detection

Web and proxy logs (look back to at least January 2026):

• GET requests to /mifs/c/appstore/fob/ or /mifs/c/aftstore/fob/ that contain gPath[ or theValue, especially with long h= or st= parameters (Unit 42, watchTowr). Response codes are often 404 even when the command ran.
• Requests that hang for about five seconds. Attackers used sleep 5 to test whether a target was vulnerable (Unit 42).
• Any request to /mifs/403.jsp, especially with the parameter k0f53cf964d387 or a large Base64 value starting with yv66vg. Responses containing 3cd3d, e60537 or ERROR:// (Defused).
• Requests to 401.jsp, 1.jsp or /favicon.png under the external web root, and downloads of /tmp or /tmpno from it (Telekom Security).
• The user agent Edg/143.0.0.1.

Network:

• DNS lookups or outbound connections from EPMM to OAST and request-catcher services: oast.live, oast.fun, oast.site, oast.me, oast.pro, oastify.com, webhook.site, requestrepo.com, ceye.io, eyes.sh, interacth3.io, cdn365.top and ngrok-free.app (Unit 42, Telekom Security).
• Outbound connections on 443 to the reverse-shell addresses listed above, and downloads of the Nezha monitoring agent (Unit 42).

On the appliance (with Ivanti support):

• New or modified JSP files in /mi/tomcat/webapps/mifs/, and .css write-test files under its css/ folder.
• /var/www/ext/html/favicon.png that isn’t an image, and odd one- or two-character files in /, /tmp and /var/tmp. BSI saw 7z-compressed malware there.
• The setuid bit set on /usr/bin/env or /bin/sh, a binary named sysd, and evidence of mysqldump --databases mifs or tar of /mi/files/system.