{"uuid": "b6451050-d58c-4bfb-8ea2-a433b2c89297", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "name": "Ivanti EPMM - CVE-2026-1281 &amp; CVE-2026-1340", "description": "# Security Advisory Ivanti Endpoint Manager Mobile (EPMM) (CVE-2026-1281 &amp; CVE-2026-1340)\n\nhttps://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-CVE-2026-1281-CVE-2026-1340?language=en_US\nhttps://forums.ivanti.com/s/article/Analysis-Guidance-Ivanti-Endpoint-Manager-Mobile-EPMM-CVE-2026-1281-CVE-2026-1340?language=en_US\n\nArticle Number : 000104594\n\n## Summary \nIvanti has released updates for Endpoint Manager Mobile (EPMM) which addresses two critical severity vulnerabilities. Successful exploitation could lead to unauthenticated remote code execution. \n\nWe are aware of a very limited number of customers whose solution has been exploited at the time of disclosure. \n\nThis 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.  \n##\u00a0Vulnerability Details: \n \n| CVE Number        | Description                                                                 | CVSS Score (Severity) | CVSS Vector                         | CWE     |\n|-------------------|-----------------------------------------------------------------------------|------------------------|--------------------------------------|---------|\n| 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 |\n| 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 |\n\n## Affected Versions \n| Product Name                    | Affected Version(s)                                  | Affected CPE(s)                                                                 | Resolved Version(s) | Patch Availability |\n|---------------------------------|------------------------------------------------------|----------------------------------------------------------------------------------|---------------------|--------------------|\n| Ivanti Endpoint Manager Mobile  | 12.5.0.0 and prior<br>12.6.0.0 and prior<br>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 |\n| Ivanti Endpoint Manager Mobile  | 12.5.1.0 and prior<br>12.6.1.0 and prior              | cpe:2.3: a:ivanti:endpoint_manager_mobile:12.5.1.0:*:*:*:*:*:*:*<br>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 |\n\n\n\nCustomers 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. \n\nNo downtime is required to apply this patch, and we are not aware of any feature functionality impact with this patch.  \n\nRPM_12.x.0.x Applicable versions: 12.5.0.x, 12.6.0.x and 12.7.0.x\n\n\t- Compatible Versions: 12.3.0.x and 12.4.0.x \n\t\nRPM_12.x.1.x Applicable Versions: 12.5.1.0 and 12.6.1.0 \n\nImportant: 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. \n\nCustomers need to prefix the support.mobileiron.com credentials while using the install rpm command.  \n\nBelow you can find the Syntax to run the patch: \n\n```\n\t\tinstall rpm url https://username:password@support.mobileiron.com/mi/vsp/AB1771634/ivanti-security-update-1761642-1.0.0S-5.noarch.rpm\n```\n\nOR  \n\n```\n    install rpm url https://username:password@support.mobileiron.com/mi/vsp/AB1771634/ivanti-security-update-1761642-1.0.0L-5.noarch.rpm  \n```\n\nThe username and password are the customers software download credentials. For more detailed instructions, please leverage the following steps.\n\nWe 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.  \n\nCustomers 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. \n\nNote: 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. \n\n# Analysis Guidance Ivanti Endpoint Manager Mobile (EPMM) \n\nThe 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 &amp; 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.  \n\nIt 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. \n\nIvanti Endpoint Manager (Ivanti EPM) is a different product and not impacted by this vulnerability. Ivanti Neurons for MDM is not impacted by this vulnerability. \n\nBefore 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 \nLimitations on Atomic Indicators \n\nDue 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. \n\nIf more reliable information becomes available in the future, Ivanti will update this page. The last revision date is at the top. \nLog Analysis \n\nCVE-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. \n\nThe following regular expression can be used to quickly triage httpd log files: \n\n```\n^(?!127\\.0\\.0\\.1:\\d+ .*$).*?\\/mifs\\/c\\/(aft|app)store\\/fob\\/.*?404 \n```\nDeployments 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: \n\n```\n127.0.0.1:33354 - - 2026-01-28--12-00-01 \"GET /mifs/c/aftstore/fob/3/0/sha256:kid=0 HTTP/1.1\" 404 \n```\n\nThe 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). \nReviewing for post-exploit persistence \n\nBased on Ivanti\u2019s analysis of threat actor toolkits targeting older vulnerabilities of the Ivanti EPMM application, we have seen two common methods of persistence. \n\nThe 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. \n\nThe 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. \nOff-box logging \n\nBased on Ivanti\u2019s 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. \n\nTo 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 \n\n## Impact \n\n### EPMM \n\nSuccessful 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.\n\n| Category                              | Description |\n|--------------------------------------|-------------|\n| Information about the EPMM Administrator | First and Last Name<br>Business Email Address<br>Account Username |\n| Information about a device user       | Account Username<br>First and Last Name<br>Email Address<br>User Principal Name (Active Directory) |\n| Information about mobile devices     | Phone number(s)<br>Nearest cell tower location<br>GPS location<br>Device Identifier (UUID or SSAID)<br>IMEI<br>ICCID (iOS)<br>IMSI or MEID<br>Azure AD Device ID (Windows only)<br>Wi-Fi, Bluetooth, Ethernet MAC Address<br>Installed applications (name and version)<br>IP Address<br>UUID<br>GCM or APNs Token |\n\n\n\nIn general, any information that is available on EPMM\u2019s MIFS portal should be considered as available to an attacker after a successful exploit. \n\nIn 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: \n\n- EPMM administrators for new or recently changed administrators. \n\n-  Authentication configuration, including SSO and LDAP settings. \n\n-  New pushed applications for mobile devices. \n\n- Configuration changes to applications you push to devices, including in-house applications. \n\n- New or recently modified policies. \n\n- Network configuration changes, including any network configuration or VPN configuration you push to mobile devices. \n\nPlease note that this is general guidance and Ivanti has not observed or received any indication that such changes have been made to a customer\u2019s EPMM appliance maliciously. \nSentry \n\nWhile 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. \nRemediation and Recovery \n\nDue 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. \n\n#### Option 1: \n\nOur 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. \n\nThe log analysis should provide indication of date/time of first successful exploit. \n\nConsidering the vulnerability to have remained unpatched, you may have to check for a backup that is previous to the earliest log entry (IoC). \n\n#### Option 2: \n\nIf 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 \n\nAdditional 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 \n\nNOTE: 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. \n\nAfter restoring the system, we recommend making the following additional changes to help secure your environment: \n\n  -  Reset the password of any local EPMM accounts. \n\n  -  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 \n\n  -  Revoke and replace the public certificate used for your EPMM. \n\n  -  Reset the password for any other internal or external service accounts configured with EPMM solution. \n\n### Scanning Activity \n\nIvanti 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. \n\nDetails on Location Tracking Services \n\nEPMM collects Device location based on privacy policy settings. It is disabled by default. The feature is applicable for iOS and Android platforms. \n\nYou 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 \n\nThis 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 \nConcerning Encrypted Private Keys in Core Database \n\nIvanti EPMM stores encrypted private keys along with hashed passwords in database when customers enable the \u201cStore keys on Core\u201d 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. \n\nHowever, 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 \n\n\n\n## FAQ \n\n1.   Are you aware of any active exploitation of these vulnerabilities?\n\nWe are aware of a very limited number of customers who have been exploited at the time of disclosure. \n\n2.  How can I tell if I have been compromised? \n\nThe investigation is ongoing and Ivanti does not have reliable atomic indicators at this time. We are providing a Technical Analysis for defenders HERE.  \n\n3.  Is Sentry vulnerable? \n\nNo, 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. \n\nCustomers who use Sentry with a cloud product are not impacted by this vulnerability.  \n\n4.  Is Ivanti Neurons for MDM vulnerable?\n\nNo. Ivanti Neurons does not contain this vulnerability. Ivanti cloud solutions are not impacted by this vulnerability. \n\n5.  What actions have Ivanti taken in response to this discovery? \n\nIn 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.  \n\n6.  Will HA sync apply the RPM patch to our secondary core if a secondary core is being used? \n\nNo, the RPM patch needs to be applied to each core separately. HA Sync will not apply the patch to any secondary cores automatically. \n\n7.  Do I need to apply both RPM patches? \n\nNo. The RPM patches are version specific, not vulnerability specific. You only need to apply the RPM patch that corresponds with your version. \n\n8.  How do I validate if the RPM was applied successfully? \n\nWhen the RPM is installed, there will be a response line indicating success. An error of any kind will be generated if there\u2019s an issue with the application. \n\n9.  What should I do if I need help?", "creation_timestamp": "2026-01-30T16:23:13.508288+00:00", "timestamp": "2026-01-30T16:30:27.952036+00:00", "related_vulnerabilities": ["CVE-2026-1340", "CVE-2026-1281"], "author": {"login": "Thanat0s", "name": "Paul Jung", "uuid": "960883df-3257-4fd3-bdd2-466a6cd98783"}}