Ivanti Sentry CVE-2026-10520: Root RCE Is Now Exploited

Ivanti Sentry CVE-2026-10520 is no longer just a patch Tuesday-style advisory. CISA added the flaw to its Known Exploited Vulnerabilities catalog on June 11, giving federal agencies until June 14 to apply vendor mitigations, after public proof-of-concept code and internet exploitation reports turned the bug into an emergency for exposed Sentry appliances.^[2]

Ivanti disclosed two critical Sentry vulnerabilities on June 9: CVE-2026-10520, an OS command injection issue that can give a remote unauthenticated attacker root-level remote code execution, and CVE-2026-10523, an authentication bypass that can let an unauthenticated attacker create arbitrary administrative accounts and obtain full administrative access.^[1][6][7] Sentry, formerly MobileIron Sentry, is usually deployed as a gateway between mobile devices and back-end enterprise systems such as mail and internal applications, so a compromise can sit close to credentials, sessions, and mobile access paths.

The exposure nuance matters. CISA says CVE-2026-10520 can be exploited when the Sentry appliance is in an unmanaged state and its endpoints are externally reachable; it also notes that using mutual TLS with EPMM, or restricted HTTPS access through Neurons for MDM, can make the relevant interfaces inaccessible to external actors.^[2] That does not make the issue theoretical for defenders: Sentry is an edge-facing mobility component, and edge appliances have repeatedly become initial-access targets, as seen in recent exploited VPN and mobile-management cases covered by HowToFix.guide, including Ivanti EPMM CVE-2026-6973, Check Point VPN CVE-2026-50751, and Cisco SD-WAN CVE-2026-20182.

What Sentry admins should check now

The affected branches are Sentry 10.5.1 and earlier, 10.6.1 and earlier, and 10.7.0 and earlier. Ivanti’s fixed releases are 10.5.2, 10.6.2, and 10.7.1, and security teams should prioritize internet-exposed or unmanaged Sentry systems first.^[1][4] If an appliance was reachable after the public analysis appeared, treat patching as only the first step: preserve logs, look for newly created administrative accounts, unexpected configuration changes, web shells or unfamiliar files, and outbound connections from the appliance to infrastructure that does not belong to the organization.

WatchTowr published technical analysis and a public test script after diffing vulnerable and patched Sentry versions, describing a pre-authentication path to command execution.^[3] Help Net Security’s June 11 update cited Shadowserver observations of a large volume of exploitation attempts based on the public PoC and reported that at least two of 19 visible vulnerable instances had been backdoored, with a warning that remaining unpatched systems were likely compromised too.^[4] Rapid7 also updated its emergency-threat response note on June 11 with mitigation guidance for the two Sentry flaws.^[5]

For response teams, the practical order is simple: verify the Sentry version, restrict management and HTTPS exposure where possible, update to the appropriate fixed branch, rotate credentials and tokens that may have transited through the gateway, and run forensic triage before putting an exposed appliance back into normal service. The key mistake would be assuming that a patched gateway is automatically clean if it was internet-reachable during the public PoC window.