Ivanti Sentry's 10.0 bug is the shape defenders should learn to recognize
CVE 2026 10520 is the structural story: an exposed API under Apache Tomcat parses attacker input as a root privileged MICS command. A version check is not the hard part.
CVE 2026 10520 is the structural story: an exposed API under Apache Tomcat parses attacker input as a root privileged MICS command. A version check is not the hard part.
Most Ivanti patch advisories read the same way: two critical CVEs, an urgent upgrade call, a line about no confirmed in-the-wild exploitation. The June 10 disclosure for Ivanti Sentry fits that template, but the underlying shape of the worst bug, CVE-2026-10520, deserves more than a "patch now" headline. The vulnerability lives in an exposed API on a mobile gateway that ships as part of Ivanti's unified endpoint management platform, and it gives an unauthenticated remote attacker a path straight to root. Patches 10.5.2, 10.6.2, and 10.7.1 close it. Whether the closure is actually live in a given deployment is a separate question.
The Register's Connor Jones reported on June 10 that Ivanti disclosed two critical vulnerabilities in Sentry, the mobile gateway component of its UEM platform: CVE-2026-10520 at CVSS 10.0 and CVE-2026-10523 at CVSS 9.9. Ivanti's advisory says there is no confirmed exploitation of the 10.0 bug as of disclosure, but the technical details are already public. Independent research lab watchTowr has published a breakdown of the patch diff, which lowers the bar for anyone with a Sentry deployment to test against.
CVE-2026-10520 is the structural story. The vulnerable component is an API endpoint that runs under Apache Tomcat. That endpoint accepts an attacker-supplied string, parses it as a MICS configuration command, and hands the result to a backend handler that executes it with root privileges. There is no authentication on the path. A remote, unauthenticated attacker who can reach the Sentry instance can hand the system a string, the system runs it as root, and the attacker gets a shell on the host. The CVSS 10.0 is not a rounding choice. It reflects a complete pre-authentication compromise of the host running the gateway.
CVE-2026-10523 is a different shape but the same exposure model. It is a pre-authentication bypass that lets a remote, unauthenticated attacker create an admin account and walk into the management plane with top-level privileges. CVSS 9.9 fits that, because once an attacker can create an admin account, they are effectively inside. The two bugs do not need to be chained to be serious. Each one on its own hands the keys to a different part of the system to anyone who can reach the instance.
What the patch actually changed matters more than the version number. For CVE-2026-10520, the fix does two concrete things. First, the dynamic MICS configuration string is gone, replaced with a hard-coded command, so attacker input can no longer be parsed and executed by the backend handler. Second, the Apache configuration is updated to block unauthenticated access to the affected endpoint. That second change is the one a defender can verify outside the application. It lives in the Apache ruleset that fronts Sentry, and it should be visible to anyone who can read the configuration. A deployment that shows the right version but still has the old endpoint reachable from an unauthenticated context is not actually protected, and an attacker probing the instance will not be reading version strings anyway.
The recurrence is worth naming. In January 2026, Ivanti fixed two 9.8 CVSS flaws in Endpoint Manager Mobile, the Sentry-adjacent product, that were exploited as zero-days before the patch shipped. The Dutch data protection authority later reported to its own parliament that it had been breached in that campaign. The June 10 Sentry disclosure fits the same pattern: pre-authentication, internet-reachable, root or admin level, and in the 9.8 to 10.0 band. That is a category of bug, not a coincidence. The category has shown up in Ivanti-adjacent UEM products often enough that an IT or security team running any of these products should be asking whether their exposure model assumes these components are not on the open internet, and whether that assumption has been checked recently.
What to verify after patching:
The honest limit on this read is that the technical mechanism for CVE-2026-10520 is drawn from the patch analysis published by watchTowr and from Ivanti's own advisory, as relayed by The Register. The "no in-the-wild exploitation" line is the vendor's reckoning, not an independent telemetry feed. CISA's Known Exploited Vulnerabilities catalog is the load-bearing check for whether the timeline is preventative or forensic. If either CVE shows up there, the calculus changes immediately, and the verification list above stops being about next week's audit and starts being about last week's incident.