When Ivanti removed the embargoes from CVE-2026-1281 and CVE-2026-1340 - actively exploited pre-auth Remote Command Execution vulnerabilities in Ivanti’s Endpoint Manager Mobile (EPMM) solution - we sighed with relief. Clearly, the universe had decided to continue mocking Secure-By-Design signers right on schedule - every January. Welcome back to another monologue that doubles as some sort of industry-wide counseling session we must all get through together. As we are always keen to remind everyone, today’s blog post didn’t ruin your weekend. The APT currently exploiting these vulnerabilities, and your lack of response to the warnings from Ivanti and CISA, did. Very Briefly, What Is EPMM? Ivanti Endpoint Manager Mobile (EPMM) is an enterprise mobility management (MDM/UEM) platform used to manage, secure, and enforce policy on mobile devices, apps, and content across iOS, Android, and other endpoints. It is commonly deployed by large organizations to control corporate mobile fleets, distribute apps, and protect access to enterprise resources. “protect”. Move On watchTowr, What's Going On Today? In this week's episode of "advisories issued by Ivanti" - https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-CVE-2026-1281-CVE-2026-1340?language=en_US , we see that two vulnerabilities have been detailed: As always, the following line in the advisory sticks out like a sore thumb: We are aware of a very limited number of customers whose solution has been exploited at the time of disclosure. “We are aware” and “very limited” are likely (in our opinion, this is probably not fact, etc, etc) to be doing a significant amount of lifting. For avoidance of doubt, the following versions of Ivanti EPMM are patched: None “But watchTowr, what do you mean?” Well, Ivanti are issuing patches-with-commitment-issues (you have to reapply after any subsequent changes in the future, or they, of course get rolled back) - until Q1 2026 when they release 12.8.0.0. Yikes? These temporary, patches-with-commitment-issues RPMs are (as of writing) called: ivanti-security-update-1761642-1.0.0L-5.noarch.rpm ivanti-security-update-1761642-1.0.0S-5.noarch.rpm To signal even more severity, it’s clear that this ‘is bad’ as they got insta-added to CISA’s KEV list. So, without further ado.. let’s dig in… The Beginning As we mentioned, Ivanti delivered RPM patches to customers under embargo (and are still paywalled) to help implement mitigations: For the purposes of this analysis, we’re focusing on the RPM patch relating to 12.7.0.0. rpm doubles up as an ultra-hacking tool (put that in your IoCs, F5) , allowing us to see what files are stored within the package. We can see that it stores two uncompiled Java files: AFTUrlMapper.java AppStoreUrlMapper.java So far so good! But what actually happens to those files? We can again use rpm to list the contents that will be executed during the installation. For this purpose, we will use the following command: rpm -qlp --scripts ivanti-security-update-1761642-1.0.0L-5.noarch.rpm Let’s go through the important steps, one by one. The first important fragments of the script are as follows: /etc/alternatives/javac /tmp/ivanti-security-update-1761642/AppStoreUrlMapper.java /etc/alternatives/javac /tmp/ivanti-security-update-1761642/AFTUrlMapper.java We can see that Java classes are being compiled - quite logical. Afterwards, we are seeing some basic filesystem-based operations. /bin/echo "Step-2 : Applying patches..." /bin/cp /tmp/ivanti-security-update-1761642/AppStoreUrlMapper.class /mi/bin/AppStoreUrlMapper.class /bin/chown root:root /mi/bin/AppStoreUrlMapper.class /bin/chmod 700 /mi/bin/AppStoreUrlMapper.class /bin/cp /tmp/ivanti-security-update-1761642/AFTUrlMapper.class /mi/bin/AFTUrlMapper.class /bin/chown root:root /mi/bin/AFTUrlMapper.class /bin/chmod 700 /mi/bin/AFTUrlMapper.class Compiled classes are moved to the /mi/bin directory and prepared for execution. Boring stuff aside, we have reached an actually interesting part. Suddenly, the script started modifying the Apache HTTPd config: /bin/sed -i \\ -e 's|RewriteMap mapAppStoreURL prg:/mi/bin/map-appstore-url|RewriteMap mapAppStoreURL "prg:/bin/java -cp /mi/bin AppStoreUrlMapper"|g' \\ -e 's|RewriteMap mapAftStoreURL prg:/mi/bin/map-aft-store-url|RewriteMap mapAftStoreURL "prg:/bin/java -cp /mi/bin AFTUrlMapper"|g' \\ /mi/config-system/xsl/httpd_ssl_conf.xsl This looks like so much fun! It seems that Ivanti EPMM: Has two Apache RewriteMap instances defined. Which point to the shell scripts: /mi/bin/map-appstore-url and /mi/bin/map-aft-store-url . After the patch, the aforementioned Bash scripts are no longer used. The patch modifies the RewriteMap instructions, which now leverage the newly introduced Java classes, entirely replacing said Bash scripts. This clearly indicates one thing - the vulnerability must exist somewhere in those Bash scripts (or, Ivanti's new approach to vulnerabilities is to refactor everything - ...