CVE-2026-10520: Ivanti Sentry OS Command Injection Under Active Exploitation

CVE-2026-10520 is an OS command injection flaw (CWE-78) in Ivanti Sentry's ConfigServiceController. The vulnerable code path processes the message parameter of a POST request sent to the /mics/api/v2/sentry/mics-config/handleMessage endpoint through a handleMessage() function that fails to sanitize attacker-controlled input before it reaches a system command call. Because the endpoint does not require authentication, an attacker who can reach it over the network can execute arbitrary operating system commands with root privileges on the underlying appliance. There is no privilege escalation step and no credential requirement standing between an attacker and full system control, which is why this vulnerability was assigned the maximum CVSS base score of 10.0.

A companion flaw disclosed alongside it, CVE-2026-10523, is a separate authentication bypass (CWE-288, CVSS 9.9) that lets an unauthenticated attacker create arbitrary administrative accounts on the same appliance. The two vulnerabilities were disclosed together and patched together, but they are distinct bugs with distinct mechanisms. This advisory focuses on CVE-2026-10520, the command injection.

Ivanti's advisory identifies three affected branch lines: Ivanti Sentry 10.7.0 and below, 10.6.1 and below, and 10.5.1 and below. Ivanti shipped fixed builds in 10.7.1, 10.6.2, and 10.5.2. If you run Sentry, confirm your build number against those three fixed versions directly against the vendor advisory rather than assuming a recent-looking version number is safe, since the branch structure means a system can be current within its own branch and still be vulnerable if it has not been bumped past the specific patch release.

For broader context on why internet-facing gateway and management appliances like Sentry draw this level of attacker attention, see our practitioner guide on edge device security for enterprise. Sentry sits in the same architectural category as VPN gateways and firewall management planes: a single internet-reachable box that, once compromised, gives an attacker leverage over everything it manages.

Ivanti disclosed CVE-2026-10520 on June 9, 2026, and at that time stated it was not aware of any customers being exploited. That changed fast. Exploitation attempts were observed within a day of disclosure, and CISA added CVE-2026-10520 to its Known Exploited Vulnerabilities catalog on June 11, 2026, based on evidence of active exploitation, a two-day turnaround from disclosure to confirmed-exploited status. This platform's threat library carries the CVE as exploited=true on the strength of that CISA KEV listing.

We want to be precise about the limits of that confirmation. CISA KEV confirms exploitation is occurring; it does not by itself name who is doing it. No specific threat actor or intrusion set has been publicly attributed to CVE-2026-10520 exploitation with the kind of confidence this platform requires before naming one in an advisory, so we are not naming one here. This is the same caution we apply across our Ivanti coverage: our post on the Ivanti Connect Secure stack overflow zero-day, CVE-2025-0282, documents a separate exploitation event in a different product where attribution details were more firmly established at the time of writing. Treat the absence of a named actor here as an honest data gap, not an indication that exploitation is any less real.

Our platform maintains detection content specific to CVE-2026-10520's handleMessage command-injection pattern, translated into vendor-specific variants for Splunk, Elastic, Microsoft Sentinel and Defender, CrowdStrike, SentinelOne, Cortex XDR, QRadar, and Chronicle, alongside the underlying Sigma rule and retrospective hunt queries covering the same pattern. Since Ivanti Sentry is a proprietary appliance rather than an EDR-monitored host, several EDR-native vendor variants are not applicable; detect and hunt via the appliance's own API access logs forwarded to a SIEM instead, using the general practices below as a starting point.

Before assuming your environment is clear, validate on two fronts: version and evidence of prior compromise. First, confirm your Sentry build number against the vendor advisory, since the fix landed as three separate branch-specific releases (10.7.1, 10.6.2, 10.5.2) rather than one universal patch. Second, because exploitation began within a day of public disclosure and Ivanti's own initial assessment of no customer impact did not hold up, treat any system that was running an affected version between the June 9, 2026 disclosure date and the date you applied the patch as a candidate for compromise, not just a candidate for patching. Review authentication logs, admin account lists, and available host telemetry for that window specifically.

This platform's threat library carries a confirmed set of Respond actions for CVE-2026-10520, and they map directly onto the facts above. Detect and Hunt content also exists for this threat, covered in the detection guidance above, but patching and containment remain the priority given how quickly exploitation began after disclosure.

Because no Sigma rule, hunting query, or MITRE ATT&CK mapping exists yet in this platform's library for CVE-2026-10520, treat network isolation and the version check above as your primary control, not detection, until that content lands. A two-day gap between disclosure and KEV listing is fast even by 2026 standards, and detection content for gateway-appliance command injection tends to lag version-check guidance by days to weeks. No specific threat actor, campaign, or victim count has been attributed with confidence, and CISA's KEV listing is the only corroborating source in this platform's data, so if you see a named actor or a victim count cited elsewhere, trace it back to its primary source before repeating it in your own reporting. Recheck this advisory against CISA's KEV catalog and Ivanti's own security advisory page directly if more than a few weeks have passed since your last read, since attribution and detection content for a fast-moving KEV entry like this one is exactly what tends to get added after initial publication. For the structural fix to a detection gap like this one, see our guide to patch management for Linux servers and network devices.