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
Affected and fixed versions
| Product / branch | Fixed in |
|---|---|
| Sentry R10.7.0 and earlier | R10.7.1 or later |
| Sentry R10.6.1 and earlier | R10.6.2 or later |
| Sentry R10.5.1 and earlier | R10.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 withexecute system /configuration/system/commandexecand 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
- Ivanti security advisory (CVE-2026-10520 and CVE-2026-10523)
- CISA Known Exploited Vulnerabilities catalog
- watchTowr technical analysis
- CVE-2026-83527 record (later Sentry fixes)
- Rapid7 analysis
- Arctic Wolf bulletin
- CERT-EU advisory 2026-008
- BleepingComputer, Shadowserver exploitation report
- SecurityWeek, Ivanti's updated advisory
Page changelog
- Full analysis published.
KEV status, EPSS score and vendor data refreshed automatically, last on 13 Oct 2026.