Critical Ivanti Sentry RCE Under Active Exploitation

Enterprise security gateways are designed to act as hardened barriers, but when they fail, they provide attackers with direct, privileged access to internal networks. A prime example is the critical security flaw in Ivanti Sentry (formerly MobileIron Sentry), tracked as CVE-2026-10520. With a maximum CVSS score of 10.0, this unauthenticated remote code execution (RCE) vulnerability is undergoing active exploitation in the wild. The Cybersecurity and Infrastructure Security Agency (CISA) added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog on June 11, 2026, imposing an urgent three-day remediation deadline.

Anatomy of the Vulnerability

CVE-2026-10520 is an OS command injection vulnerability (CWE-78) residing within Sentry's MICS (MobileIron Configuration Service) configuration API. Specifically, the /mics/api/v2/sentry/mics-config/handleMessage endpoint accepts unauthenticated HTTP POST requests.

When a request is received, the payload is processed by a Spring Boot REST controller. This controller passes the user-supplied input to a configuration handler, which parses XML-formatted commands. The application then uses Java reflection to dynamically execute these commands on the underlying operating system.

Because input validation is entirely absent on this endpoint, attackers can craft a message parameter containing arbitrary system commands. The execution occurs with root-level privileges, and the server returns the command output directly in the HTTP response. This immediate feedback loop provides attackers with an interactive, unauthenticated read/write shell.

The Companion Auth Bypass

Alongside the command injection flaw, Ivanti's advisory addresses CVE-2026-10523, a critical authentication bypass with a CVSS score of 9.9. This vulnerability allows remote, unauthenticated attackers to bypass security controls and create arbitrary administrative accounts on the Sentry appliance.

Because both flaws share the same affected code paths, they are addressed by the same software updates. A public proof-of-concept (PoC) exploit released by watchTowr Labs chains these weaknesses, allowing attackers to either execute commands directly or establish persistent administrative access. The affected versions span all R10.5.x, R10.6.x, and R10.7.x release trains prior to the patched versions.

In-the-Wild Exploitation

While Ivanti's initial advisory stated there was no evidence of active exploitation, real-world telemetry quickly contradicted this. The Shadowserver Foundation reported a surge in exploitation attempts immediately following the release of the public PoC. According to Shadowserver, scanning efforts detected multiple vulnerable instances exposed to the internet, with several already backdoored. The organization warned that because many Sentry deployments blocklist search engine crawlers, the actual number of compromised gateways is likely significantly higher than public scans indicate.

Security gateways like Sentry are highly attractive targets because they typically sit in the DMZ, managing and encrypting traffic between mobile devices and backend corporate systems, such as Microsoft Exchange. Compromising a Sentry appliance gives an attacker a strategic pivot point to intercept ActiveSync traffic, access internal applications, and move laterally across the enterprise network.

Identification and Auditing Workflow

Given the severity of the threat, organizations must immediately identify and audit all Sentry instances. A structured discovery workflow involves several steps:

1. Port Scanning: By default, the Sentry MICS web application listens on port 8443 (HTTPS). Security teams should scan perimeter and DMZ subnets for this port, as well as port 443 (which may front Sentry via a reverse proxy) and port 9090 (often used for the admin console).
2. TLS Certificate Inspection: Sentry appliances frequently employ self-signed TLS certificates. Inspecting certificates on port 8443 for issuer or subject fields containing "Ivanti", "MobileIron", or "Sentry" can quickly confirm the identity of the host.
3. HTTP Endpoint Probing: The MICS application runs under the /mics context path on an Apache Tomcat server. Probing /mics/login.jsp will reveal Spring Boot and Tomcat headers. Crucially, sending a request to the vulnerable /mics/api/v2/sentry/mics-config/handleMessage endpoint serves as a diagnostic test: patched instances will return a 302 Redirect to the login page, whereas unpatched instances will return an HTTP 200 OK status code.
4. DNS and Infrastructure Mapping: Querying internal and external DNS records for common naming conventions (e.g., sentry-*, gateway-*, mobileiron-*) can uncover forgotten deployments. Sentry is often paired with Ivanti Endpoint Manager Mobile (EPMM), so identifying hosts like epmm-* or mdm-* can point to associated Sentry gateways.

Remediation and Defense

The primary remediation path is upgrading Ivanti Sentry to versions R10.5.2, R10.6.2, or R10.7.1. These releases address the vulnerability by hardcoding command inputs to prevent injection and implementing Apache rewrite rules that block unauthenticated access to the /mics/api/ paths, forcing a redirect.

If immediate patching is not feasible, organizations should implement strict firewall rules to restrict access to port 8443 to trusted management networks only. Additionally, Ivanti notes that deployments utilizing mutual TLS (mTLS) for communication with EPMM, or those restricting HTTPS access via Neurons for MDM, have a significantly reduced attack surface because the vulnerable MICS API interfaces are not exposed to the public internet. Finally, defenders should review web server logs for any POST requests targeting /mics/api/v2/sentry/mics-config/handleMessage and inspect the system for unauthorized processes or newly created administrative accounts.