An OS Command Injection vulnerability in Ivanti Sentry before the R10

CVE-2026-10520 is an unauthenticated OS command injection in Ivanti Sentry's MICS API. On affected releases before R10.5.2, R10.6.2, and R10.7.1, a remote attacker can hit the exposed /mics application and coerce the appliance into running attacker-supplied operating-system commands as root. Public technical analysis from watchTowr ties exploitation to the unauthenticated POST /mics/api/v2/sentry/mics-config/handleMessage path, and runZero notes the affected population as 10.5.1, 10.6.1, 10.7.0, and prior, with older unsupported builds likely affected too.

Vendor severity is not inflated here; if anything, the user-supplied intel is already stale. Although you provided KEV listed: No, NVD now shows this CVE was added to CISA KEV on 2026-06-11, which means there is authoritative evidence of exploitation in the wild. Combine that with a public PoC, no authentication requirement, root execution, and the fact that Sentry commonly lives at the edge brokering traffic to Exchange and other internal services, and this stays firmly in CRITICAL.

Why this verdict

• No-auth remote root RCE means the attack starts at initial access, not after foothold, VPN, or stolen creds
• KEV on 2026-06-11 is a hard upgrade signal over the prompt's stale KEV listed: No field
• Gateway placement amplifies impact because Sentry brokers mobile access to internal services and commonly has trusted paths to sensitive backends

Why not higher?

It cannot go meaningfully higher than this; this is already top-bucket material. The only moderating factor is product prevalence: Sentry is a narrower target class than mass-market edge software, so enterprise-wide exposure depends on whether you actually run it.

Why not lower?

There is no auth requirement, no user interaction, no local foothold prerequisite, and no exotic environmental dependency beyond reachability to the service. Once KEV and public PoC enter the picture, any argument for downgrading to HIGH collapses unless your Sentry estate is fully isolated from attacker reach.

1. Isolate exposed Sentry immediately — If any Sentry instance is reachable from the internet or broadly reachable internal segments, restrict access to trusted admin networks or a VPN-only path within hours. Because this CVE is KEV-listed, the normal CRITICAL mitigation window is overridden by live exploitation evidence.
2. Block the vulnerable MICS endpoint — Add reverse-proxy, WAF, NGFW, or load-balancer rules to deny POST access to /mics/api/v2/sentry/mics-config/handleMessage from untrusted sources within hours. This is the most direct temporary break in the exploit chain if full upgrade cannot happen immediately.
3. Enable and tune IPS signatures — Push available protections such as the Check Point Ivanti Sentry Remote Code Execution (CVE-2026-10520) signature within hours to catch opportunistic scanning and replay of the public PoC. This is detection-and-disruption, not a substitute for patching.
4. Hunt for post-exploitation artifacts — Review /var/log/mics/, auth logs, new local accounts, and suspicious files under /tmp, /var/tmp, and /dev/shm within hours. A gateway appliance compromise is not self-contained; assume credential and config exposure until proven otherwise.
5. Rotate secrets touched by the appliance — If compromise indicators exist or exposure was prolonged, rotate credentials, certificates, and trust relationships used by Sentry within 3 days because root on the appliance likely exposed them. This contains downstream abuse after the initial foothold.

Run this on the Sentry appliance shell after you have console or SSH access. Invoke it as sudo bash ./check-cve-2026-10520.sh 10.6.1 if you already know the installed version, or sudo bash ./check-cve-2026-10520.sh to let it try RPM-based detection; root is recommended because some package queries and file reads may be restricted.

#!/usr/bin/env bash
# check-cve-2026-10520.sh
# Defensive local version check for Ivanti Sentry CVE-2026-10520
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/runtime error

set -u

extract_version() {
  local s="$1"
  echo "$s" | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1
}

ver_lt() {
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ]
}

ver_ge() {
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$2" ]
}

VERSION_INPUT="${1:-}"
VERSION=""
SOURCE=""

if [ -n "$VERSION_INPUT" ]; then
  VERSION="$(extract_version "$VERSION_INPUT")"
  SOURCE="argument"
fi

if [ -z "$VERSION" ] && command -v rpm >/dev/null 2>&1; then
  RPM_HIT="$(rpm -qa 2>/dev/null | grep -Ei 'ivanti|mobileiron|sentry' | head -n1 || true)"
  if [ -n "$RPM_HIT" ]; then
    VERSION="$(extract_version "$RPM_HIT")"
    SOURCE="rpm"
  fi
fi

if [ -z "$VERSION" ]; then
  for f in /etc/ivanti-release /etc/mobileiron-release /etc/sentry-release /opt/mobileiron/*/VERSION /opt/ivanti/*/VERSION; do
    if [ -r "$f" ]; then
      HIT="$(head -n5 "$f" 2>/dev/null | tr -d '\r' | head -n1 || true)"
      VERSION="$(extract_version "$HIT")"
      if [ -n "$VERSION" ]; then
        SOURCE="$f"
        break
      fi
    fi
  done
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN"
  echo "reason=Could not determine installed Ivanti Sentry version automatically" >&2
  exit 2
fi

echo "detected_version=$VERSION source=$SOURCE" >&2

# Supported fixed branches from vendor/public advisory chain:
# 10.5.x fixed at 10.5.2
# 10.6.x fixed at 10.6.2
# 10.7.x fixed at 10.7.1
# Older unsupported versions are likely affected, but public wording does not fully enumerate every historical branch.

if ver_ge "$VERSION" "10.7.1"; then
  echo "PATCHED"
  exit 0
fi

if ver_ge "$VERSION" "10.7.0" && ver_lt "$VERSION" "10.7.1"; then
  echo "VULNERABLE"
  exit 1
fi

if ver_ge "$VERSION" "10.6.0" && ver_lt "$VERSION" "10.6.2"; then
  echo "VULNERABLE"
  exit 1
fi

if ver_ge "$VERSION" "10.5.0" && ver_lt "$VERSION" "10.5.2"; then
  echo "VULNERABLE"
  exit 1
fi

if ver_lt "$VERSION" "10.5.0"; then
  echo "UNKNOWN"
  echo "reason=Version is older than enumerated supported branches; treat as at-risk and validate against vendor support records" >&2
  exit 2
fi

echo "UNKNOWN"
echo "reason=Version falls outside expected branch logic; verify manually against vendor release documentation" >&2
exit 2

Sources

1. NVD CVE record
2. Ivanti security advisory
3. watchTowr technical analysis
4. watchTowr GitHub PoC / detection artifact
5. runZero exposure and identification guidance
6. Check Point IPS advisory
7. CERT-EU advisory
8. Secondary reporting on Shadowserver-observed exploitation attempts