Your organization's entire mobile fleet -- every phone, every tablet, every device carrying corporate email and VPN configs -- is managed by a server sitting on the open internet. That server has a Bash script that doesn't sanitize user input. An attacker sends one HTTP GET request. No credentials needed. No user interaction. Game over.
That's CVE-2026-1281. And it's been getting exploited since before anyone knew it existed.
The Bug
CVE-2026-1281 is a pre-authentication remote code execution flaw in Ivanti Endpoint Manager Mobile (EPMM), formerly known as MobileIron Core. CVSS 9.8. The companion flaw, CVE-2026-1340, is the same class of bug in a different component. Same score, same impact.
EPMM is a mobile device management (MDM) platform. It pushes policies, apps, and configurations to every managed device in an organization. It stores names, email addresses, phone numbers, and GPS coordinates for every enrolled device. It has command execution privileges on Ivanti Sentry gateways, which sit between mobile devices and internal backend systems. Owning EPMM means owning the keys to the mobile kingdom, and having a direct pivot path into the internal network.
The root cause is embarrassingly simple. EPMM uses Apache RewriteMap directives that route certain HTTP requests through two Bash shell scripts: /mi/bin/map-appstore-url (for the In-House Application Distribution feature) and /mi/bin/map-aft-store-url (for Android File Transfer Configuration). These scripts process URL parameters without properly sanitizing them against Bash arithmetic expansion.
watchTowr Labs reverse-engineered Ivanti's patch and published the technical breakdown on January 30. The RPM patches replace the vulnerable Bash scripts with Java classes, which tells you exactly where the problem was. The exploitation path goes through a crafted HTTP GET request to the app store file delivery endpoint. watchTowr's proof-of-concept request looked like this:
GET /mifs/c/appstore/fob/3/5/sha256:kid=1,st=theValue,et=1337133713,h=gPath[`sleep 5`]/e2327851-1e09-4463-9b5a-b524bc71fc07.ipaThose backticks around sleep 5 are where your day goes sideways. Replace sleep 5 with a reverse shell command and the attacker owns the box. No auth. No interaction. Just one GET request to an endpoint that's supposed to serve mobile apps.
Rapid7's analysis confirmed that successful exploitation gives the attacker whatever the EPMM application has access to: personally identifiable information on every managed device, the ability to push malicious configurations to the entire device fleet, and a pivot point for lateral movement across the network.
The Timeline Nobody Had Time to React To
Here's the part that should concern you: the vendor disclosure, the CISA KEV listing, and confirmed government compromises all happened on the same day. There was no heads-up window.
January 29, 2026: Ivanti publishes its security advisory and releases interim RPM patches. CISA throws CVE-2026-1281 onto the Known Exploited Vulnerabilities catalog with a three-day remediation deadline -- February 1. That same day, Dutch authorities confirm the Dutch Data Protection Authority and the Council for the Judiciary were already compromised. NHS England, CERT-EU, and NCSC-NL also issue advisories confirming active exploitation.
January 30: watchTowr Labs drops their full technical analysis. A working proof-of-concept appears on GitHub. Finland's Valtori identifies a breach that exposed work contact details for up to 50,000 government employees.
February 1: GreyNoise sensors start recording exploitation attempts. CISA's deadline arrives.
February 4: The European Commission confirms an attack on its mobile device management infrastructure without naming the vendor. Connect the dots yourself.
February 8: Exploitation sessions spike to 269 in a single day, up from an average of 21. The floodgates are open.
February 9: Shadowserver counts 86 confirmed compromised instances. Nearly 1,300 EPMM instances are still exposed to the internet. Defused Cyber reports attackers are planting dormant webshells on compromised servers.
February 12: GreyNoise publishes their analysis showing one IP on bulletproof hosting is responsible for 83% of all observed exploitation.
February 13: CISA adds the BeyondTrust CVE-2026-1731 flaw to KEV, but circling back -- for Ivanti, the damage was already done before most orgs opened the advisory email.
By the time your security team read the advisory, reviewed the CVSS score, filed a change request, and scheduled a maintenance window, the Dutch government was already breached. That's the reality of vulnerability management in 2026.
Who's Doing the Shooting
GreyNoise tracked 417 exploitation sessions between February 1 and February 9 from 8 unique source IPs. One IP accounted for 346 of those sessions. That's 83% of all observed attacks coming from a single address: 193.24.123[.]42.
That IP sits on PROSPERO OOO (AS200593), geolocated to Saint Petersburg. Censys tags the autonomous system as "BULLETPROOF" -- meaning the hosting provider is in the business of not responding to abuse complaints.
PROSPERO has been linked by Trustwave SpiderLabs to the Proton66 network (AS198953) and the BEARHOST brand, a bulletproof hosting service marketed on Russian-language cybercrime forums. That infrastructure has a documented history of hosting distribution for GootLoader, Matanbuchus, SpyNote, Coper (Octo), and SocGholish.
This isn't a single-target operator. GreyNoise observed 193.24.123[.]42 simultaneously running exploitation campaigns against four completely unrelated products:
| Target | CVE | Sessions |
|---|---|---|
| Oracle WebLogic | CVE-2026-21962 | 2,902 |
| GNU InetUtils telnetd | CVE-2026-24061 | 497 |
| Ivanti EPMM | CVE-2026-1281 | 346 |
| GLPI (IT Asset Mgmt) | CVE-2025-24799 | 200 |
The IP cycles through over 300 user agent strings covering every major browser and OS combination. Four different software products. Hundreds of spoofed fingerprints. This is automated exploitation infrastructure running at scale.
This IP doesn't appear on any of the widely circulated IOC lists for this campaign. The IOCs that were shared after Ivanti's disclosure? GreyNoise checked. Four of them sit in a /24 block of Windscribe VPN exit nodes in Amsterdam -- zero Ivanti EPMM exploitation sessions. Another published IOC pointed to a compromised ASUS router on Swedish residential broadband that has never appeared in GreyNoise telemetry at all. If you built your detection rules around the published IOCs and called it done, you're watching the wrong door.
The Sleeper Shell Play
Mass exploitation is only half the picture. The other half is quieter and more calculated.
On February 9, Defused Cyber reported a campaign deploying dormant in-memory Java class loaders to compromised EPMM instances at the path /mifs/403.jsp. These implants have a deliberate constraint: they only activate when they receive a specific trigger parameter. Without that trigger, they sit dormant. At the time of the report, no follow-on exploitation had been observed on any of the implanted systems.
This is initial access broker tradecraft. The attacker breaks in, plants a sleeping backdoor, verifies it works, and then sells access to whoever is buying -- ransomware gangs, espionage groups, or other criminal operators. The buyer shows up later with the trigger and lights the fuse.
GreyNoise's telemetry supports this interpretation. Out of 417 exploitation sessions they observed, 85% used out-of-band application security testing (OAST) DNS callbacks. The payloads tell the compromised server to make a DNS request to a unique subdomain, which confirms command execution without requiring a direct connection back to the attacker. These payloads don't deploy malware. They don't steal data. They verify: "Can I execute commands here? Yes? Next target."
GreyNoise put it plainly: the campaign is cataloging which targets are vulnerable rather than deploying payloads immediately. This is consistent with initial access operations that verify exploitability first and deploy follow-on tooling later.
The in-memory class loaders don't survive an application server restart. But that's cold comfort. If the broker already verified access and sold it, the buyer can re-exploit the vulnerability any time the patches haven't been applied. A restart clears the implant but doesn't close the hole.
The Damage So Far
Netherlands: The Dutch Data Protection Authority (AP) and the Council for the Judiciary (Rvdr) confirmed breaches via Ivanti EPMM zero-days. The Netherlands' NCSC was directly involved in developing Ivanti's exploitation detection script, suggesting this wasn't a minor incident.
Finland: Valtori, the central government ICT service provider, disclosed that attackers accessed names, work email addresses, phone numbers, and device details for up to 50,000 government employees.
European Commission: Confirmed a cyberattack on its mobile device management infrastructure without naming the vendor. The timing and description leave little room for interpretation.
Broader scope: Shadowserver identified 86 confirmed compromised instances as of February 9. Saudi Arabia's National Cybersecurity Authority provided initial exploitation artifacts used for scanning. Multiple threat groups are now involved -- this isn't a single-actor operation anymore.
CyberScoop reported the fallout has reached nearly 100 confirmed victims. Shadowserver's CEO noted that the compromised instances they can identify were likely hit by multiple actors and that "more is happening than what we are able to observe."
Meanwhile, Rapid7 set up an EPMM honeypot that recorded hundreds of inbound connections from over 130 unique IPs in just 24 hours. Christiaan Beek, Rapid7's senior director of threat intelligence and analytics, said the dominant payloads were built for rapid control through reverse shells, webshell deployment, and automated droppers. These weren't researchers poking around.
Why Ivanti's Fix Is a Band-Aid (For Now)
Ivanti released version-specific RPM patches on January 29 and updated security patches on February 4. The patches replace the Bash scripts with Java classes, killing the injection vector. They take seconds to apply with no downtime. There's no excuse for not applying them.
But there are catches.
The RPM patches don't survive version upgrades. If you upgrade your EPMM appliance, the patch gets wiped and you have to reapply it. Ivanti says the permanent fix comes in EPMM version 12.8.0.0, expected sometime in Q1 2026.
More importantly, patching doesn't undo compromise. watchTowr's CEO Benjamin Harris was blunt: applying patches alone is not enough. Organizations that were exposing vulnerable instances to the internet when this dropped must consider them compromised, tear down infrastructure, and initiate incident response.
And there's a downstream concern most people aren't thinking about. EPMM has command execution privileges on Ivanti Sentry. Sentry routes traffic between mobile devices and internal backend systems. If EPMM is compromised, everything Sentry touches needs to be investigated for reconnaissance and lateral movement. That's a much bigger blast radius than a single server.
What To Do Right Now
If you haven't patched: Stop reading and go patch. The RPM takes seconds. No downtime. Do it now.
If you patched but were exposed between January 29 and your patch date: Assume compromise. Check for /mifs/403.jsp on your EPMM instance. Pull Apache access logs from /var/log/httpd/https-access_log and search with this regex:
^(?!127\.0\.0\.1:\d+ .*$).*?\/mifs\/c\/(aft|app)store\/fob\/.*?404If attackers cleared the logs (and they often do), you'll need your SIEM or log aggregator. If you weren't forwarding EPMM logs externally, you may have zero historical visibility. That's a gap to fix going forward.
Review DNS logs for high-entropy subdomain queries to OAST interaction domains. These indicate exploitation payloads successfully executed on your systems.
Check your admin accounts. Ivanti recommends reviewing EPMM administrators for new or recently changed accounts, SSO and LDAP authentication settings, new pushed applications, policy changes, and network or VPN configuration changes pushed to devices.
Reset credentials. If you suspect compromise, reset passwords for all local EPMM accounts, LDAP and KDC service accounts, and any service accounts configured with EPMM. Revoke and replace the public certificate on the deployment.
Block AS200593 (PROSPERO) at the perimeter. This is the autonomous system hosting the dominant exploitation source. It's bulletproof hosting with documented ties to malware distribution. There's no legitimate reason for your network to talk to it.
Restart your EPMM application server to clear any in-memory sleeper implants. This is a temporary measure -- the Java class loaders don't survive a restart -- but it buys time while you investigate.
Investigate Sentry and downstream systems. If EPMM has command execution on your Sentry gateway, and Sentry connects to internal systems, those systems are in scope for incident response.
Challenge whether EPMM needs to be internet-facing at all. If you can put it behind a VPN or zero-trust access layer, do it. MDM platforms are too high-value and too high-risk to leave exposed.
The Pattern
This is not new. Ivanti EPMM was exploited via CVE-2023-35078 in 2023. It was exploited again in 2025 through CVE-2025-4427 and CVE-2025-4428. CISA has now flagged 31 Ivanti vulnerabilities on its Known Exploited Vulnerabilities catalog since late 2021, with at least 19 exploited in the wild in the past two years alone.
The window between vulnerability disclosure and mass exploitation has collapsed to hours. In this case, there was no window at all -- the attackers were already inside before the advisory went public. The IOC lists that were supposed to help defenders were pointing at the wrong infrastructure. And the patches that were supposed to fix the problem are temporary and don't survive upgrades.
If your MDM server is on the open internet with no additional access controls, you're running the same playbook that got the Dutch Data Protection Authority and the European Commission owned. The threat actors running automated exploitation from bulletproof hosting don't care about your change management process or your maintenance window schedule.
Patch now. Investigate retroactively. And stop leaving MDM platforms exposed to the entire internet.
Sources
- GreyNoise, "Active Ivanti Exploitation Traced to Single Bulletproof IP -- Published IOC Lists Point Elsewhere," February 10, 2026
- watchTowr Labs, "Someone Knows Bash Far Too Well, And We Love It (Ivanti EPMM Pre-Auth RCEs CVE-2026-1281 & CVE-2026-1340)," January 30, 2026
- Rapid7, "Critical Ivanti Endpoint Manager Mobile (EPMM) Zero-Day Exploited in the Wild," January 30, 2026
- The Hacker News, "83% of Ivanti EPMM Exploits Linked to Single IP on Bulletproof Hosting Infrastructure," February 12, 2026
- The Hacker News, "Dutch Authorities Confirm Ivanti Zero-Day Exploit Exposed Employee Contact Data," February 11, 2026
- CyberScoop, "Fallout from Latest Ivanti Zero-Days Spreads to Nearly 100 Victims," February 9, 2026
- Defused Cyber, "Ivanti EPMM Sleeper Shells -- 403.jsp Campaign Report," February 9, 2026
- Help Net Security, "Ivanti EPMM Exploitation: Researchers Warn of Sleeper Webshells," February 11, 2026
- Arctic Wolf, "CVE-2026-1281 and CVE-2026-1340 Advisory," January 29, 2026
- Ivanti Security Advisory: CVE-2026-1281 and CVE-2026-1340
- CISA Known Exploited Vulnerabilities Catalog