Security Advisory Ivanti Endpoint Manager Mobile (EPMM) (CVE-2026-1281 & CVE-2026-1340)

https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-CVE-2026-1281-CVE-2026-1340?language=en_US https://forums.ivanti.com/s/article/Analysis-Guidance-Ivanti-Endpoint-Manager-Mobile-EPMM-CVE-2026-1281-CVE-2026-1340?language=en_US

Article Number : 000104594

Summary

Ivanti has released updates for Endpoint Manager Mobile (EPMM) which addresses two critical severity vulnerabilities. Successful exploitation could lead to unauthenticated remote code execution.

We are aware of a very limited number of customers whose solution has been exploited at the time of disclosure.

This vulnerability does not impact any other Ivanti products, including any cloud products, such as Ivanti Neurons for MDM. Ivanti Endpoint Manager (EPM) is a different product and also not impacted by these vulnerabilities. Customers using an Ivanti cloud product with Sentry are also not impacted by this vulnerability.

Vulnerability Details:

CVE Number	Description	CVSS Score (Severity)	CVSS Vector	CWE
CVE-2026-1281	Code injection in Ivanti Endpoint Manager Mobile allowing unauthenticated RCE	9.8 (Critical)	AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H	CWE-94
CVE-2026-1340	Code injection in Ivanti Endpoint Manager Mobile allowing unauthenticated RCE	9.8 (Critical)	AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H	CWE-94

Affected Versions

Product Name	Affected Version(s)	Affected CPE(s)	Resolved Version(s)	Patch Availability
Ivanti Endpoint Manager Mobile	12.5.0.0 and prior 12.6.0.0 and prior 12.7.0.0 and prior	cpe:2.3: a:ivanti:endpoint_manager_mobile:12.7.0.0:::::::*	RPM 12.x.0.x	https://support.mobileiron.com/mi/vsp/AB1771634/ivanti-security-update-1761642-1.0.0S-5.noarch.rpm
Ivanti Endpoint Manager Mobile	12.5.1.0 and prior 12.6.1.0 and prior	cpe:2.3: a:ivanti:endpoint_manager_mobile:12.5.1.0::::::: cpe:2.3: a:ivanti:endpoint_manager_mobile:12.6.1.0:::::::	RPM 12.x.1.x	https://support.mobileiron.com/mi/vsp/AB1771634/ivanti-security-update-1761642-1.0.0L-5.noarch.rpm

Customers should apply either RPM 12.x.0.x or RPM 12.x.1.x, depending on their version. Customers do not need to apply both RPMs as they are version specific, not vulnerability specific.

No downtime is required to apply this patch, and we are not aware of any feature functionality impact with this patch.

RPM_12.x.0.x Applicable versions: 12.5.0.x, 12.6.0.x and 12.7.0.x

- Compatible Versions: 12.3.0.x and 12.4.0.x

RPM_12.x.1.x Applicable Versions: 12.5.1.0 and 12.6.1.0

Important: the RPM script does not survive a version upgrade. If after applying the RPM script to your appliance, you upgrade to a new version you will need to reinstall the RPM. The permanent fix for this vulnerability will be included in the next product release: 12.8.0.0.

Customers need to prefix the support.mobileiron.com credentials while using the install rpm command.

Below you can find the Syntax to run the patch:

        install rpm url https://username:password@support.mobileiron.com/mi/vsp/AB1771634/ivanti-security-update-1761642-1.0.0S-5.noarch.rpm

OR

    install rpm url https://username:password@support.mobileiron.com/mi/vsp/AB1771634/ivanti-security-update-1761642-1.0.0L-5.noarch.rpm  

The username and password are the customers software download credentials. For more detailed instructions, please leverage the following steps.

We strongly encourage all EPMM customers to adopt version 12.8.0.0 once it has been released later in Q1 2026. Once you have upgraded to 12.8.0.0, you will not need to reapply the RPM script. We are providing Technical Analysis that includes affected endpoint specifics and log analysis guidance which can be found below to support investigation and forensics.

Customers should determine their own risk appetite when securing their environment. The most conservative approach, regardless of exploitation, would be to build a replacement EPMM and then migrate data to the device. You can find instructions on how to do this HERE. This does not require re-enrollment of devices.

Note: Ivanti is dedicated to ensuring the security and integrity of our enterprise software products. We recognize the vital role that security researchers, ethical hackers, and the broader security community play in identifying and reporting vulnerabilities. Visit HERE to learn more about our Vulnerability Disclosure Policy.

Analysis Guidance Ivanti Endpoint Manager Mobile (EPMM)

The information in this document includes threat indicators and defensive measures and was created for the purpose of assisting Ivanti customers and defenders as they examine their Ivanti EPMM solution for any impact due to the recently disclosed Remote Code Execution vulnerabilities (CVE-2026-1281 & CVE-2026-1340). This document includes information about reviewing logs for potential exploitation, details about potential impact from successful exploitation, and methods for recovery and remediation.

It is important for you to know that neither CVE-2026-1281 nor CVE-2026-1340 impacts Ivanti Sentry. However, the EPMM must have access to Sentry, including the execution of commands, for Sentry to function and the configuration to be maintained. As such, this document also includes information on reviewing Ivanti Sentry for potential lateral movement. Customers who use Ivanti Sentry with their Neurons for MDM do not need to follow this guidance.

Ivanti Endpoint Manager (Ivanti EPM) is a different product and not impacted by this vulnerability. Ivanti Neurons for MDM is not impacted by this vulnerability.

Before performing any analysis, we strongly recommend you apply the latest security patches. The latest information for protecting your EPMM from both CVEs is available here: https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-CVE-2026-1281-CVE-2026-1340 Limitations on Atomic Indicators

Due to the small number of known-impacted customers, Ivanti does not have enough information about the threat actor tactics to provide proven, reliable atomic indicators. This document will focus on more generic information about detecting attempted exploitation instead of reconnaissance or post-exploitation activities.

If more reliable information becomes available in the future, Ivanti will update this page. The last revision date is at the top. Log Analysis

CVE-2026-1281 and CVE-2026-1340 affect the In-House Application Distribution and the Android File Transfer Configuration features. The Apache Access Log (/var/log/httpd/https-access_log) will record attempted and successful exploitation of both vulnerabilities. If you use these features, you may see legitimate traffic to these endpoints. Legitimate use of these capabilities will result in 200 HTTP response codes in the Apache Access Log whereas successful or attempted exploitation will cause 404 HTTP response codes. We recommend reviewing these and any other GET requests with parameters that have bash commands.

The following regular expression can be used to quickly triage httpd log files:

^(?!127\.0\.0\.1:\d+ .*$).*?\/mifs\/c\/(aft|app)store\/fob\/.*?404 

Deployments that have been patched will generate legitimate heartbeat requests to the service. The above regular expression is written to exclude such events. An example of the heartbeat is below:

127.0.0.1:33354 - - 2026-01-28--12-00-01 "GET /mifs/c/aftstore/fob/3/0/sha256:kid=0 HTTP/1.1" 404 

The on-box logging can be manipulated by a threat actor who has successfully exploited the system. We strongly recommend reviewing your SIEM or other log aggregator/collector rather than the logs from the system itself (see Off-box logging instructions below). Reviewing for post-exploit persistence

Based on Ivanti’s analysis of threat actor toolkits targeting older vulnerabilities of the Ivanti EPMM application, we have seen two common methods of persistence.

The most common is the introduction of, or modification of, malicious files to introduce web shell capabilities. Ivanti has commonly seen these changes target HTTP error pages, such as 401.jsp. Any requests to these pages with POST methods or with parameters should be considered highly suspicious. Analysts who are performing forensic inspection of the disk should also review for unexpected WAR or JAR files being introduced to the system.

The latter is the deployment of reverse shells. The Ivanti EPMM appliance does not commonly make outbound network connections. We recommend reviewing firewall logs for long-running connections initiated by the appliance. Off-box logging

Based on Ivanti’s analysis of threat actor toolkits targeting older vulnerabilities on the Ivanti appliance, analysts should assume that the threat actor techniques will likely include the clearing of logs or removal of specific log entries. Furthermore, the log files on an EPMM appliance are rotated based on both the size and time range. Systems with high utilization and/or increased logging, such as debug logging, may see their logs rotate multiple times a day.

To ensure you can investigate issues on your appliance, we strongly recommend you make use of our Data Export features to forward logs from your EPMM solution to a SIEM. More information about forwarding logs using syslog can be found here: https://help.ivanti.com/mi/help/en_us/core/11.x/sys/CoreSystemManager/Data_Export__SysLog.htm

Impact

EPMM

Successful exploitation of the EPMM appliance will enable arbitrary code execution on the appliance. Aside from lateral movement to the connected environment, EPMM also contains sensitive information about devices managed by the appliance. Below is the list of potentially available data types.

Category	Description
Information about the EPMM Administrator	First and Last Name Business Email Address Account Username
Information about a device user	Account Username First and Last Name Email Address User Principal Name (Active Directory)
Information about mobile devices	Phone number(s) Nearest cell tower location GPS location Device Identifier (UUID or SSAID) IMEI ICCID (iOS) IMSI or MEID Azure AD Device ID (Windows only) Wi-Fi, Bluetooth, Ethernet MAC Address Installed applications (name and version) IP Address UUID GCM or APNs Token

In general, any information that is available on EPMM’s MIFS portal should be considered as available to an attacker after a successful exploit.

In addition to obtaining the above information, the API can be used to make changes to the EPMM configuration. If the changes are made through the API or web console, these changes are logged. Depending on your risk tolerance, you may want to review your EPMM configuration. For any appliance that you suspect may be impacted, we would recommend you review:

• EPMM administrators for new or recently changed administrators.

• Authentication configuration, including SSO and LDAP settings.

• New pushed applications for mobile devices.

• Configuration changes to applications you push to devices, including in-house applications.

• New or recently modified policies.

• Network configuration changes, including any network configuration or VPN configuration you push to mobile devices.

Please note that this is general guidance and Ivanti has not observed or received any indication that such changes have been made to a customer’s EPMM appliance maliciously. Sentry

While EPMM can be restricted to a DMZ with little to no access to the rest of a corporate network, Sentry is specifically intended to tunnel specific types of traffic from mobile devices to internal network assets. If you suspect that your EPMM appliance is impacted, we recommend you review the systems that Sentry can access for potential recon or lateral movement. Remediation and Recovery

Due to the complexity of the EPMM product, Ivanti does NOT recommend attempting to clean the system after it has been compromised. If your system is confirmed compromised, there are two options for restoring your device to a known-good state.

Option 1:

Our preferred recommendation is to restore your Ivanti EPMM from existing, known good backups from your enterprise backup solution or from virtual machine snapshots. When choosing the optimal backup solution, please take into consideration the exploit timing.

The log analysis should provide indication of date/time of first successful exploit.

Considering the vulnerability to have remained unpatched, you may have to check for a backup that is previous to the earliest log entry (IoC).

Option 2:

If it is not possible to recover your EPMM from a backup, Ivanti recommends building a replacement EPMM and then migrating data to the device. Information on how to do this can be found here: https://forums.ivanti.com/s/article/EPMM-Rebuild-the-EPMM-with-options

Additional documentation on the System Backup feature can be found here: https://help.ivanti.com/mi/help/en_us/core/11.x/sys/CoreSystemManager/System_backup.htm

NOTE: In both cases above, it is critical to restore the system while it is not available to the internet and then apply the approved mitigation or patches before returning the system to service. You can safely return the system to service once all remediation and recovery actions are completed.

After restoring the system, we recommend making the following additional changes to help secure your environment:

• Reset the password of any local EPMM accounts.

• Reset the password the LDAP and/or KDC service accounts perform lookups. https://help.ivanti.com/mi/help/en_us/core/11.x/gsg/CoreGettingStarted/Configuring_LDAP_servers.htm

• Revoke and replace the public certificate used for your EPMM.

• Reset the password for any other internal or external service accounts configured with EPMM solution.

Scanning Activity

Ivanti expects security researchers, both individuals and organizations, to begin scanning internet-facing appliances for this specific endpoint after the patch is released. Such scanning will make it more difficult to separate scanning from exploit attempts. Besides advising you to review the source of the IP addresses, there is no additional advice Ivanti can provide to separate scanning activity from attempted exploit.

Details on Location Tracking Services

EPMM collects Device location based on privacy policy settings. It is disabled by default. The feature is applicable for iOS and Android platforms.

You can find information about how the service is configured here: https://help.ivanti.com/mi/help/en_us/core/11.x/gsg/CoreGettingStarted/Privacy_policies.htm

This is where you can see the data through the admin console: https://help.ivanti.com/mi/help/en_us/CORE/12.x/dmga/DMGfiles/Locate.htm Concerning Encrypted Private Keys in Core Database

Ivanti EPMM stores encrypted private keys along with hashed passwords in database when customers enable the “Store keys on Core” feature. Even with significant expertise in the EPMM product, it is difficult to be able to obtain a password and successfully decrypt the private keys. Ivanti has never seen this performed in the wild. More information on this feature can be found here: https://help.ivanti.com/mi/help/en_us/CORE/12.x/dmga/DMGfiles/Cert_Enroll_s_1_ConfigSCEP.htm. This feature is disabled by default.

However, Ivanti recommends revoking previously generated user certificates and regenerating using admin driven action from the EPMM product. Instructions for revoking certifications can be found here: https://help.ivanti.com/mi/help/en_us/CORE/14.x/dmga/DMGfiles/About_logs_CertMgmt.htm#troubleshooting_3631632413_1032053

FAQ

1. Are you aware of any active exploitation of these vulnerabilities?

We are aware of a very limited number of customers who have been exploited at the time of disclosure.

1. How can I tell if I have been compromised?

The investigation is ongoing and Ivanti does not have reliable atomic indicators at this time. We are providing a Technical Analysis for defenders HERE.

1. Is Sentry vulnerable?

No, Sentry does not contain this vulnerability, however you should always review the security of the Sentry appliance at the same time as EPMM due to the dependency it has on the EPMM appliance and configuration.

Customers who use Sentry with a cloud product are not impacted by this vulnerability.

1. Is Ivanti Neurons for MDM vulnerable?

No. Ivanti Neurons does not contain this vulnerability. Ivanti cloud solutions are not impacted by this vulnerability.

1. What actions have Ivanti taken in response to this discovery?

In addition to rapidly and proactively providing a patch, Ivanti has mobilized additional resources and support teams to assist customers and is actively collaborating with security partners, the broader security community and law enforcement.

1. Will HA sync apply the RPM patch to our secondary core if a secondary core is being used?

No, the RPM patch needs to be applied to each core separately. HA Sync will not apply the patch to any secondary cores automatically.

1. Do I need to apply both RPM patches?

No. The RPM patches are version specific, not vulnerability specific. You only need to apply the RPM patch that corresponds with your version.

1. How do I validate if the RPM was applied successfully?

When the RPM is installed, there will be a response line indicating success. An error of any kind will be generated if there’s an issue with the application.

1. What should I do if I need help?