In a significant alert for cybersecurity professionals, Ivanti has disclosed two critical zero-day vulnerabilities within its Endpoint Manager Mobile (EPMM) solution that are being actively exploited in the wild, compelling an urgent response from organizations that rely on the platform. The severity of the situation was underscored when the U.S. Cybersecurity and Infrastructure Security Agency (CISA) promptly added one of the flaws to its Known Exploited Vulnerabilities catalog, signaling a clear and present danger to federal agencies and private sector companies alike. These vulnerabilities permit unauthenticated remote code execution, giving attackers a powerful foothold into compromised systems. With Ivanti confirming that a limited number of its customers have already been targeted, the race is on for administrators to patch their systems and hunt for any signs of a breach before threat actors can cause further damage.
1. Deconstructing the Technical Flaws
The two vulnerabilities, identified as CVE-2026-1281 and CVE-2026-1340, both carry a critical CVSS score of 9.8 out of 10, reflecting the extreme risk they pose. They are categorized as code injection flaws that allow an unauthenticated attacker to execute arbitrary code remotely on a vulnerable appliance. These security gaps are located within specific components of the EPMM, namely the In-House Application Distribution and the Android File Transfer Configuration features. Successful exploitation could grant an adversary complete control over the EPMM appliance, enabling them to move laterally across the network and access a trove of sensitive information stored on the devices managed by the system. Ivanti has clarified that these issues do not impact its other offerings, such as Ivanti Neurons for MDM, Ivanti Endpoint Manager (EPM), or Ivanti Sentry, narrowing the scope of concern to EPMM users. However, for those affected, the potential for data exfiltration and persistent access makes immediate mitigation a top priority.
The patch rollout for these flaws requires careful attention from administrators due to its temporary nature. The vulnerabilities impact a range of versions, including EPMM 12.5.0.0, 12.6.0.0, 12.7.0.0, 12.5.1.0, and 12.6.1.0, along with all prior releases. Ivanti has provided an RPM patch to address the immediate threat, but it comes with a significant caveat: the patch does not persist through a version upgrade. This means that if an appliance is upgraded to a new version of EPMM, the RPM patch must be manually reapplied to maintain protection. A permanent fix that fully integrates the security updates is slated for release with EPMM version 12.8.0.0, which is expected later in the first quarter of 2026. This staggered approach places a heavy burden on IT teams to not only apply the initial patch but also to track its status and reapply it as needed until the permanent solution becomes available, adding a layer of complexity to the remediation process.
2. A Guide to Detection and Remediation
Given the active exploitation of these vulnerabilities, organizations must assume compromise and immediately begin threat-hunting activities. Ivanti has provided specific guidance for detecting malicious activity by examining server logs. Administrators are urged to inspect the Apache access log located at /var/log/httpd/https-access_log, using a specific regular expression pattern to search for anomalous entries. A key indicator of compromise is the presence of 404 HTTP response codes related to the affected aft or appstore paths. While legitimate use of these features would typically generate a 200 HTTP response code, failed or successful exploitation attempts will trigger a 404 error, creating a distinct digital footprint for investigators to follow. This log analysis is the first critical step in determining whether an environment has been targeted and helps security teams to quickly identify the scope of a potential intrusion before moving on to containment and eradication measures.
Beyond log analysis, a comprehensive review of the EPMM configuration is essential to uncover any unauthorized modifications made by an attacker. This includes meticulously checking for any new or recently changed administrator accounts, as creating rogue admin accounts is a common tactic for maintaining persistence. Authentication settings, particularly for SSO and LDAP, should be scrutinized for any alterations that could weaken security. Additionally, administrators must review the list of applications being pushed to mobile devices for any new or unfamiliar software, as well as configuration changes to legitimate applications. It is also crucial to audit all policies for recent modifications and to inspect network configurations, including any VPN settings being distributed to endpoints. Any deviation from a known-good baseline in these areas could be evidence of a compromise, warranting a full-scale incident response.
3. The Anatomy of an Exploit
A technical deep dive conducted by security researchers at watchTowr Labs provided crucial insights into how these vulnerabilities are exploited. By reverse-engineering the patches, the team discovered that the flaws reside within two Bash shell scripts: /mi/bin/map-appstore-url and /mi/bin/map-aft-store-url. The temporary RPM fix works by modifying the Apache HTTPd configuration to replace these vulnerable scripts with more secure Java classes. This analysis revealed that an attacker could trigger the vulnerability by sending a specially crafted HTTP GET request to a specific endpoint. The request leverages parameters processed by the Bash script—including a start time, end time, and a SHA256 hash—which are intended to facilitate the retrieval of mobile applications from the approved app store. However, an attacker can manipulate these inputs to inject and execute arbitrary shell commands on the server.
The exploit vector is alarmingly straightforward, as demonstrated by the proof-of-concept request. By sending an HTTP request to an endpoint like /mifs/c/appstore/fob/3/5/sha256:kid=..., an attacker can cause the Apache server to execute the vulnerable Bash script with user-controlled input. This direct line to command execution on the appliance highlights the critical nature of the flaw. Because threat actors were leveraging this as a zero-day, any internet-facing EPMM instance that was unpatched at the time of disclosure should be considered compromised. Applying the patch is a necessary first step, but it is not sufficient on its own. Organizations must proceed with full incident response protocols, which include isolating affected systems, conducting a thorough forensic investigation, and rebuilding infrastructure from a known-good state to ensure all traces of the threat actor have been removed.
A Path Forward After the Breach
The disclosure of these Ivanti EPMM vulnerabilities served as a critical reminder of the persistent threats facing enterprise infrastructure. Organizations that followed the guidance were required to initiate a multi-faceted response that went beyond simple patch application. Successful mitigation involved a meticulous process of log analysis, configuration auditing, and, in confirmed cases of compromise, a complete system restoration from trusted backups. The incident prompted many security teams to re-evaluate their incident response plans and asset management practices, recognizing that any internet-exposed system represents a potential entry point for attackers. The requirement to reset credentials for local accounts, service accounts, and certificates after a breach underscored the deep level of access that could be achieved through these flaws. This event ultimately reinforced the importance of proactive threat hunting and maintaining a defense-in-depth security posture to protect against sophisticated zero-day attacks.
