CVE-2026-10520: Ivanti Sentry Unauthenticated OS Command Injection — How to Find Exposed Instances

Ivanti Sentry (formerly MobileIron Sentry) contains a pre-authentication OS command injection vulnerability that gives remote attackers root-level code execution. CVSS 10.0, actively exploited in the wild, CISA KEV listed with a 3-day remediation deadline. A public PoC is available from watchTowr Labs. Here's how to find Ivanti Sentry appliances on your network.

The Vulnerability

CVE-2026-10520 (CWE-78: OS Command Injection) is a maximum-severity vulnerability in Ivanti Sentry's MICS configuration API. The /mics/api/v2/sentry/mics-config/handleMessage endpoint accepts unauthenticated POST requests and passes user-supplied input directly to OS command execution via Java reflection — no credentials, no user interaction, root-level access.

The attack is trivial: send a POST request with a crafted message parameter containing an execute system command. The payload passes through a Spring Boot REST controller into a configuration handler that parses XML-formatted commands and invokes them via Java reflection. The response includes the command output, making this a full read/write RCE with immediate feedback.

What Is Ivanti Sentry?

Ivanti Sentry (formerly MobileIron Sentry) is an in-line gateway that manages, encrypts, and secures traffic between mobile devices and backend enterprise systems. It typically sits in the DMZ controlling ActiveSync email traffic and enforcing device-level access decisions for Microsoft Exchange, working alongside Ivanti Endpoint Manager Mobile (EPMM). Compromising Sentry gives an attacker a pivot point into email servers, internal applications, and the broader enterprise network.

Related: CVE-2026-10523 (Authentication Bypass)

The same advisory covers CVE-2026-10523 (CVSS 9.9) — a separate authentication bypass that allows remote unauthenticated attackers to create arbitrary administrative accounts and gain full admin access to the Sentry appliance. Both vulnerabilities share the same affected and fixed versions. The watchTowr PoC covers both CVEs.

Investigation Workflow

Ivanti Sentry appliances are typically deployed in DMZs with direct internet exposure — exactly where you'd expect them to be reachable by attackers. With a public PoC and active exploitation, finding every Sentry instance on your network is urgent. Here's how to do it with RECON.

1. Port Scan: Find Sentry Appliances

Ivanti Sentry listens on port 8443 (HTTPS) by default. Scan your DMZ and perimeter subnets for this port. Also check:

• • 8443 — Sentry HTTPS (primary — MICS web application)
• • 443 — May be used via reverse proxy
• • 9090 — Sentry admin console (some deployments)

Any host with port 8443 open in a DMZ segment is worth investigating further.

2. TLS Inspect: Identify Ivanti Certificates

Pull the TLS certificate on port 8443. Ivanti Sentry appliances commonly use self-signed certificates with identifying characteristics:

• • Subject or issuer fields containing Ivanti, MobileIron, or Sentry
• • Certificates originally issued to MobileIron (pre-acquisition naming)
• • Self-signed certificates on non-standard HTTPS ports

3. HTTP Headers: Fingerprint the MICS Application

The vulnerable application runs under the /mics context path on a Tomcat server. Probe for:

• • /mics/login.jsp — Sentry login page (returns Spring Boot application response)
• • Patched instances return 302 redirects to login when hitting the vulnerable endpoint; unpatched return 200
• • Tomcat and Spring Boot indicators in response headers
• • Ivanti or MobileIron branding in login pages and error messages

4. DNS: Discover Sentry Infrastructure

Query internal DNS for common Sentry naming patterns: sentry-*, gateway-*, mobilegateway-*, mobile-security-*, mobileiron-*, ivanti-*. Sentry appliances are often deployed alongside EPMM infrastructure, so look for related hosts like epmm-* or mdm-* — they may point to the same deployment.

5. CVE Lookup: Confirm the Advisory

Use RECON's CVE Lookup to pull the full NVD entry for CVE-2026-10520. The CISA KEV listing with a June 14 deadline means federal agencies and organizations following BOD 26-04 have 3 days to remediate. Check CVE-2026-10523 as well — both vulnerabilities affect the same versions and require the same patch.

Cross-Reference with External Data

Remediation

1. Patch immediately. Upgrade Ivanti Sentry to R10.5.2, R10.6.2, or R10.7.1. The patch hardens the vulnerable endpoint by hardcoding command input and adding Apache rewrite rules that block unauthenticated access with a 302 redirect.
2. Restrict network access to port 8443. If patching takes time, use firewall rules to restrict access to the Sentry HTTPS port from trusted management networks only. Block all external access to /mics/api/ paths.
3. Use mTLS where possible. Ivanti notes that deployments using mTLS with EPMM or restricted HTTPS access through Neurons for MDM have reduced exposure because the vulnerable interfaces are not externally reachable.
4. Check for compromise indicators. Review Sentry logs for POST requests to /mics/api/v2/sentry/mics-config/handleMessage. Look for unexpected system processes, new user accounts, or modified configuration files — the RCE runs as root.
5. Address CVE-2026-10523 in parallel. The authentication bypass (CVSS 9.9) allows attackers to create admin accounts. Same patch fixes both — but verify no rogue admin accounts were created before patching.
6. Audit your EPMM infrastructure. If Sentry was compromised, the attacker may have pivoted to EPMM, Exchange, or other internal services behind the gateway. Review EPMM logs, Exchange mailflow rules, and Active Directory for lateral movement indicators.

Sources

• → Ivanti Security Advisory: CVE-2026-10520 & CVE-2026-10523
• → NVD: CVE-2026-10520
• → NVD: CVE-2026-10523
• → watchTowr Labs: Ivanti Sentry Pre-Auth RCE Analysis
• → CISA Known Exploited Vulnerabilities Catalog