Is CVE-2026-10520 (Ivanti Sentry OS Command Injection) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2026-10520 to its Known Exploited Vulnerabilities catalogue on 11 June 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Ivanti Sentry (formerly known as MobileIron Sentry) contains an OS command injection vulnerability which could allow a remote unauthenticated user to achieve root-level remote code execution.

What CVE-2026-10520 Means for Exposure

CVE-2026-10520 is not just a vulnerability label. Because the issue is an OS command injection in an internet-facing appliance, the practical question is whether your Ivanti Sentry instances are reachable, internet-exposed, and still within a deployment pattern that attackers can hit without valid credentials. That is the first exposure check before any deeper response work.

For teams that treat Sentry as an edge control, the immediate task is to confirm where the appliance sits in the environment, whether management interfaces are exposed, and whether any compensating controls actually reduce attacker reach. NHI Management Group’s Edge Device Security Guide is relevant here because the same failure pattern appears when gateway-class systems are left reachable from untrusted networks.

Why Command Injection on an Edge Appliance Is High Risk

Command injection on a perimeter appliance matters because the vulnerable service typically runs with elevated system privileges and is reachable before other security controls can help. In this case, the direct answer already states that exploitation can lead to root-level remote code execution, which means an attacker who lands the exploit may gain the same authority as the appliance itself.

That is why an exploited gateway should be treated as both a vulnerability and a potential compromise event. The issue is not only code execution, but also what else the appliance can reach, observe, or proxy once a hostile command is running. CISA Known Exploited Vulnerabilities Catalog is the operational signal that confirms the issue has crossed from theoretical exposure into active exploitation prioritisation.

When organisations still need a technical reference for exploited vulnerabilities, NHI Management Group’s Zero-Day and Exploited Vulnerabilities Guide is useful for the response pattern, even when the flaw is not a zero-day in the strict sense.

What to Do While You Validate and Contain

Start with asset confirmation, then move to containment. Identify every Ivanti Sentry deployment, verify whether it is internet-facing, and compare the deployed state with the vendor advisory and the CISA KEV entry rather than relying on local assumptions about versioning or patch status. If patching is already complete, that does not end the work, because active exploitation can leave behind persistence or stolen material.

If patching or maintenance must wait, reduce exposure immediately by limiting reachability, tightening access paths, and preserving logs and forensic data before they roll over. For a structured prioritisation sequence, NHI Management Group’s Vulnerability Management Guide aligns well with the decision points that matter here: exposure, verification, exception handling, and post-fix validation.

For teams that need to think in exploitability terms rather than generic patch queues, NIST National Vulnerability Database helps anchor the record, while CVE Program remains the canonical identifier source for the vulnerability itself. If you also need a likelihood layer for prioritisation, FIRST EPSS is the right complementary signal, but it should not override confirmed exploitation evidence from CISA.

Risk and Threat Considerations

An actively exploited command injection on a border appliance creates a short path from external reachability to full system control. The main threat is not just initial code execution, but post-exploitation use of the appliance as a foothold for reconnaissance, credential harvesting, pivoting, or tampering with security functions that depend on it.

Failure mechanism: The appliance accepts attacker-supplied input that is interpreted as operating-system commands, allowing unauthenticated remote execution under high privilege and creating a direct path to compromise.

Impact: Attackers may gain root-level control, extract secrets or sessions, alter logs, and use the device as a stable foothold for deeper network access or follow-on compromise.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	The question is about active exploitation and urgent remediation of a known vulnerability.
Recommendation — Prioritise remediation for KEV-listed flaws and verify exposed assets before closing the ticket.
NIST CSF 2.0	PR.IP-12 — Vulnerability Management	Known exploited vulnerability response depends on asset validation, prioritisation, and remediation workflow.
Recommendation — Track exploited vulnerabilities through a formal prioritisation and remediation process.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The issue requires timely remediation and validation of a known flaw on an exposed system.
Recommendation — Remediate the vulnerable appliance promptly and verify the fix against authoritative guidance.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	An internet-facing appliance with command injection fits public-facing exploitation paths.
Recommendation — Hunt for exploit attempts against exposed appliances and block the public attack path.
OWASP ASVS	V4 — API and Web Service Security	Command injection in a network-accessible service is an application-layer input-handling failure.
Recommendation — Validate that service inputs cannot reach command execution paths.

Practitioner Guidance

What to verify: Confirm whether every Sentry instance is covered by the vendor fix guidance and whether any device was exposed long enough to be probed before remediation. If you find an internet-facing instance, assume it belongs in your highest-priority response lane until you have validated patching, containment, and log retention.

Decision rule: If you cannot prove the appliance was unavailable to attackers during the exposure window, treat the situation as a potential compromise case, not a routine patch event. That means checking for unusual admin activity, shell execution artefacts, unexpected outbound connections, and any signs that the device touched credentials or tokens it should not have.

Practitioner takeaway: For KEV-listed edge-device flaws, the real question is not whether a patch exists, but whether the exposed appliance has already been used as an entry point and whether you have enough telemetry to prove it has not.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org