Max severity Ivanti Sentry flaw is now being exploited, and unpatched gateways are likely already compromised

The window between a patch and a working attack keeps shrinking, and Ivanti Sentry is the latest proof. Ivanti shipped fixes for a maximum-severity vulnerability on Tuesday. By Wednesday, the Shadowserver Foundation was reporting that attackers had already backdoored most of the Sentry gateways it could find exposed online. There was no slow ramp-up, no quiet reconnaissance period. The exploitation started almost immediately after a public proof-of-concept appeared.

If you run Ivanti Sentry and have not patched yet, the realistic assumption is that you are already compromised.

What the flaw actually does

Tracked as CVE-2026-10520, the vulnerability is an OS command injection weakness in Sentry, the gateway formerly sold as MobileIron Sentry. Sentry sits between back-end corporate systems and remote mobile devices, brokering traffic so that phones and tablets can reach internal resources like email and document stores. That position is exactly what makes it valuable to an attacker. A command injection bug here means an unauthenticated request can be crafted to run arbitrary operating system commands, and in this case those commands execute with root privileges.

Root on the appliance is the worst outcome you can get. The attacker is not sandboxed inside an application context or limited to reading a config file. They control the box. From a Sentry gateway, that translates into a foothold positioned at the boundary between untrusted mobile traffic and trusted internal systems, which is the entire reason these devices are an attractive target.

Ivanti addressed the issue with Sentry versions R10.5.2, R10.6.2, and R10.7.1. Those are the builds you want to be on. The fixed versions and the original advisory are published on Ivanti's security center.

The detection picture is worse than the numbers suggest

Shadowserver's scan data tells a deliberately understated story. The organization reported seeing 19 vulnerable instances in its own scans, with at least two confirmed backdoored thanks to a tip from Saudi Arabia's National Cybersecurity Authority. But the important caveat is in the next sentence.

"While our detection is on the lowish side due to multiple Ivanti Sentry instances not reachable in our scans (blocklisted?), if you have not patched now you are most likely compromised," the group warned.

That blocklisting matters. Shadowserver runs internet-wide scans to map exposed and vulnerable systems, and its scanning infrastructure is widely known, which means some operators block its source addresses. A blocked scanner sees a smaller slice of reality. So the 19 figure is a floor, not a count. The actual population of exposed Sentry gateways is larger, and Shadowserver's read is that the compromise rate across that larger population is high. When the people doing the measuring tell you the real number is bigger than what they can show you, treat the visible cases as the optimistic version.

There is a practical takeaway buried in that detail for defenders generally. Blocking security research scanners feels like reducing your attack surface, but it mostly reduces your own visibility into how exposed you are. It does nothing to stop the attackers running the same public proof-of-concept, and it removes one of the free early-warning channels that might have told you that you were sitting on a critical exposure.

A timeline that should bother you

The sequence here is the part worth internalizing. Ivanti released the patch on Tuesday and stated at the time that it had no evidence of in-the-wild exploitation. The advisory still reads, as of this writing, "We are not aware of any customers being exploited by these vulnerabilities at the time of disclosure." One day later, Shadowserver was reporting mass exploitation driven by a public proof-of-concept.

This is the pattern that has become normal for edge appliances. A patch and an advisory are also a roadmap. Once the fix is public, reverse-engineering the vulnerable code path and building an exploit is often a matter of hours for motivated actors, and the appearance of a public PoC removes even that small barrier. The vendor's "no known exploitation at disclosure" statement was almost certainly accurate when written and almost certainly obsolete within 24 hours. Both things can be true at once, which is precisely why you cannot treat the absence of exploitation evidence in an advisory as permission to wait.

For any internet-facing security appliance, the safe operating assumption is that a maximum-severity unauthenticated RCE will be exploited within days of disclosure, not weeks. Patch timelines should be built around that assumption rather than around quarterly maintenance windows.

Why Ivanti keeps showing up in these stories

This is not an isolated incident, and the broader record explains why attackers keep coming back. Multiple Ivanti zero-days have been exploited over the past few years to breach government agencies and enterprises worldwide. In January, Ivanti patched two critical Endpoint Manager Mobile (EPMM) vulnerabilities that had already been exploited as zero-days against a limited set of customers. Last month, CISA ordered U.S. federal agencies to patch a high-severity EPMM remote code execution flaw that was abused in zero-day attacks.

The cumulative number is striking. Over the past several years, CISA has flagged 34 vulnerabilities across various Ivanti products as actively exploited in the wild, and 12 of those were also used in ransomware campaigns. You can check whether a specific CVE is on that list through CISA's Known Exploited Vulnerabilities catalog.

The reason is structural, not a knock on any one vendor's code quality. Security gateways, VPN concentrators, and mobile management appliances are deliberately exposed to the internet, they hold privileged positions inside networks, and they are attractive precisely because compromising one yields access to everything behind it. Ivanti's footprint, more than 40,000 customers, over 7,000 partners, makes its products a high-value target population. The same dynamics apply to comparable products from other vendors. Edge security appliances are, paradoxically, some of the most attacked devices on any network.

What to actually do

Start with the obvious and time-sensitive step. Update to Sentry R10.5.2, R10.6.2, or R10.7.1 immediately. Given the exploitation timeline, this is not a this-week task, it is a today task.

But patching alone is not enough here, because the exploitation predates many organizations' patch windows. If your Sentry instance was internet-exposed and unpatched at any point this week, assume compromise and investigate accordingly. That means hunting for the backdoors Shadowserver described rather than just closing the hole they came through. Patching a box that is already rooted removes the entry path but leaves the attacker's persistence intact.

Concretely:

• Review the appliance for unexpected processes, files, accounts, and outbound connections. Root-level access lets an attacker install persistence that survives a patch.
• Compare current configuration against a known-good baseline. Command injection at root can modify anything on the device.
• Check logs for anomalous requests matching the exploitation pattern, keeping in mind that an attacker with root may have tampered with local logs. Centralized or upstream logging is more trustworthy here.
• Rotate credentials and secrets that the gateway had access to, on the assumption they may have been exposed.
• If you cannot confidently rule out compromise, rebuild from known-good media rather than trusting a cleanup.

The uncomfortable reality of the Shadowserver guidance is that the default posture should be one of assumed breach, not assumed safety. When a credible scanning organization tells you that unpatched means compromised and that its own visibility understates the problem, the prudent response is to treat your Sentry gateway as a crime scene until your investigation proves otherwise.

The larger lesson extends well past this one CVE. Internet-facing security appliances need a faster patch cadence and a different mental model than internal servers. They are the front door, they run with high privilege, and the gap between a published fix and a weaponized exploit is now routinely measured in hours. Build your response process around that timeline, because the attackers already have.