Sentry

CVE-2026-10520: Unauthenticated root command execution on Ivanti Sentry gateways

One unauthenticated POST to a Sentry management API runs commands as root (CVSS 10). Exploited within a day of a public proof of concept; Shadowserver found backdoored gateways. Exposure depends on how Sentry is managed.

Published Updated

ExploitedYes, in CISA KEVAdded 11 Jun 2026
Ransomware useNot reportedPer CISA
SeverityCRITICALCVSS 3.1 10
EPSS100%Chance of exploitation in 30 days
Public exploitYes
FixAvailable

Affected and fixed versions

Product / branchFixed in
Sentry R10.7.0 and earlierR10.7.1 or later
Sentry R10.6.1 and earlierR10.6.2 or later
Sentry R10.5.1 and earlierR10.5.2 or later

Always confirm against the vendor advisory, which lists every fixed hotfix.

What it is

Ivanti Sentry (formerly MobileIron Sentry) is the gateway that connects mobile devices managed by EPMM or Neurons for MDM to internal resources. Its management API has an endpoint, /mics/api/v2/sentry/mics-config/handleMessage, that accepted requests without authentication. The message parameter is parsed as an internal configuration command. When it is execute, the text inside a <commandexec> XML block is passed to the operating system and runs as root (watchTowr, Rapid7).

That is a full takeover of a gateway that brokers mobile traffic into your network, with one HTTP request.

watchTowr published a proof of concept the day after Ivanti’s advisory. The same day, Shadowserver reported a large number of exploitation attempts and found at least 2 of the 19 vulnerable gateways it could see were already backdoored. It warned that the rest were likely compromised too. CISA added the CVE to the KEV catalog on June 11.

Ivanti’s position is narrower. It says it saw attempted exploitation of honeypots, and that real deployments are much less exposed because of how Sentry is managed (next section).

The same advisory fixes CVE-2026-10523, an authentication bypass that lets attackers create admin accounts. Both are fixed in the same releases.

Am I affected?

You’re running a vulnerable version if Sentry is before R10.5.2, R10.6.2 or R10.7.1.

Whether attackers can reach the bug depends on the management port, 8443. Ivanti says exploitation needs access to it, and CISA’s KEV entry says the flaw is exploitable when Sentry is unmanaged and its endpoints are reachable from outside:

  • Managed by EPMM: the vulnerable APIs are protected by mutual TLS (mTLS) once Sentry is managed, so outsiders can’t reach them.
  • Managed by Neurons for MDM: Ivanti recommends restricting internet access to the API whatever your deployment. Restricted HTTPS access makes it unreachable.
  • Unmanaged: a Sentry that isn’t managed by EPMM or Neurons for MDM has the API exposed. Ivanti says such an appliance can’t serve production traffic, but labs, half-finished deployments and replaced gateways that are still online all count.

Check from outside your network whether port 8443 on each Sentry answers. If it does and the appliance is on an affected version, treat it as exploitable, and treat it as possibly compromised if it was exposed on or after June 10, 2026.

What to do

1. Upgrade to R10.5.2, R10.6.2, R10.7.1 or later. Ivanti says this is the only full fix, and it also closes CVE-2026-10523. Pick the newest build, not the minimum: in September Ivanti fixed another unauthenticated Sentry flaw, CVE-2026-83527, that needs R10.6.4, R10.7.3 or R10.8.2.

2. Block the management port from the internet. Use firewall rules, ACLs or a reverse proxy so that 8443 and the /mics/api/ path are reachable only from trusted management networks (Arctic Wolf). Do this even after patching.

3. Find and remove unmanaged appliances that are still online, or bring them under EPMM or Neurons for MDM management.

4. If an affected appliance’s port 8443 was reachable from the internet, investigate before trusting it.

  • Look for the activity described below.
  • Review Sentry’s administrator accounts and remove any you didn’t create. CVE-2026-10523 lets attackers add admins.
  • If you find signs of compromise, rebuild the appliance rather than cleaning it, and rotate any credentials stored on it.
  • Check the internal systems Sentry connects to for unusual activity from the Sentry appliance’s address.

Detection

  • POST requests to /mics/api/v2/sentry/mics-config/handleMessage, especially from outside your management networks. Arctic Wolf says a 200 response to an unauthenticated request means the appliance is likely vulnerable. On fixed versions, unauthenticated requests are redirected to the login page with a 302 (watchTowr).
  • Request bodies with a message= parameter starting with execute system /configuration/system/commandexec and containing a <reqandres> element. That element holds the command that was run (watchTowr).
  • New administrator accounts in Sentry (Arctic Wolf).
  • Unexpected processes started by the Sentry web service, new scheduled tasks or cron jobs, and outbound connections from the appliance to the internet that it doesn’t normally make (Arctic Wolf).
  • Shadowserver notifies network owners of vulnerable and backdoored Sentry appliances. If you subscribe to its free reports, check its Vulnerable HTTP report for the tag cve-2026-10520.

Indicators of compromise

No IP addresses, hashes or file names have been published for this CVE. Checked Ivanti, Shadowserver, watchTowr, Rapid7, Arctic Wolf and CISA. Shadowserver shares affected IP addresses with network owners in its Vulnerable HTTP report.

No indicators of compromise have been published for this CVE yet. We'll add them here if the vendor or a researcher releases any. Until then, use the behaviour in Detection.

Sources

Page changelog

  • Full analysis published.

KEV status, EPSS score and vendor data refreshed automatically, last on 13 Oct 2026.

Get alerts

A notification when we publish a new analysis or a covered vendor gets a new actively exploited CVE. No account, no email.