CVE-2026-10520

What it actually does

This vulnerability is an unauthenticated, network-reachable OS command injection flaw in Ivanti Standalone Sentry. An attacker can send crafted requests to an affected Sentry appliance and cause the underlying operating system to execute attacker-controlled commands with root privileges. Because exploitation requires no credentials, no user interaction, and has low attack complexity, successful exploitation can result in full appliance compromise, including arbitrary command execution, persistence deployment, credential or configuration theft, traffic interception, service disruption, and use of the appliance as a foothold into connected enterprise networks.

Why it matters to the business

A vulnerable Ivanti Sentry appliance can be fully taken over remotely, potentially exposing mobile access infrastructure, credentials, configuration data, and network connectivity that the appliance brokers or protects. Compromise may lead to operational outages, unauthorized access to internal services, data theft, lateral movement, and costly incident response. The CVSS score is critical, EPSS is extremely high, exploitation is reported in the wild, and the vulnerability is in the CISA Known Exploited Vulnerabilities catalog with a remediation deadline of 2026-06-14, making this an urgent patch-or-isolate issue for any organization running affected versions.

How an attack unfolds

An attacker first identifies an internet-facing or otherwise reachable Ivanti Standalone Sentry appliance and determines that it is running a vulnerable release before R10.5.2, R10.6.2, or R10.7.1. The attacker then sends a specially crafted unauthenticated request to the vulnerable component, embedding shell metacharacters or command syntax in a parameter that is improperly passed to the operating system. The appliance executes the injected command as root. After initial code execution, the attacker commonly runs reconnaissance commands, retrieves configuration and credential material, establishes persistence, stages tooling, creates reverse shells or outbound command-and-control channels, and may pivot toward adjacent systems that trust or communicate with Sentry. Because exploitation has been observed in the wild and the EPSS score is near-maximal, defenders should assume exposed vulnerable systems are likely to be targeted rapidly and should investigate for prior compromise even after patching.

How to fix it

Upgrade Ivanti Standalone Sentry to a fixed release immediately: R10.5.2 or later for the R10.5 branch, R10.6.2 or later for the R10.6 branch, or R10.7.1 or later for the R10.7 branch. If immediate upgrade is not possible, remove the appliance from internet exposure, restrict management and service interfaces to trusted networks only, enforce upstream access controls, and monitor/block suspicious command-injection patterns at reverse proxies or network security controls where feasible. Because this is root-level unauthenticated RCE and is actively exploited, mitigation should be treated as temporary only. For any appliance that was exposed while vulnerable, perform incident response before returning it to service: collect forensic evidence, rotate credentials and certificates stored on or passing through the appliance, review integrations and trust relationships, and consider rebuilding from known-good media if compromise cannot be ruled out.

How to confirm the fix worked

Confirm the running Ivanti Standalone Sentry version from the administrative interface or vendor-supported command-line/version reporting method and verify it is R10.5.2, R10.6.2, R10.7.1, or later. Validate that no vulnerable Sentry interfaces remain reachable from untrusted networks using external attack-surface scanning and internal network scans. Where safe and authorized, use vendor-provided checks or non-destructive vulnerability assessment signatures to confirm the command-injection endpoint no longer accepts crafted payloads. After upgrade, verify that services are healthy, configuration remains intact, and access controls restrict exposure as intended. If the appliance was previously exposed, validate remediation only after reviewing logs and filesystem artifacts for evidence of command execution, persistence, unauthorized account or key changes, suspicious outbound connections, and unexpected modifications to system or application files.

Typical attack path

1. Scan for internet-facing or internally reachable Ivanti Standalone Sentry appliances.
2. Fingerprint the Sentry version or infer vulnerability from exposed behavior and release level.
3. Send a crafted unauthenticated request containing OS command injection payloads.
4. Execute commands on the appliance with root privileges.
5. Run discovery commands to identify system version, users, network interfaces, routes, credentials, and configuration files.
6. Deploy a web shell, reverse shell, scheduled task, SSH key, modified startup script, or other persistence mechanism.
7. Exfiltrate configuration data, credentials, certificates, tokens, or logs from the appliance.
8. Use the compromised appliance to intercept traffic, disrupt service, or pivot into connected enterprise resources.

How to detect it

Investigate whether affected Ivanti Standalone Sentry appliances received suspicious unauthenticated HTTP requests before patching, especially requests containing shell metacharacters, command separators, encoded command strings, or attempts to invoke common Unix utilities. Review Sentry application logs, embedded web server logs, reverse proxy/WAF logs, firewall logs, EDR/NDR telemetry, authentication logs, system process accounting, shell history, cron and systemd configuration, SSH configuration, and outbound DNS/HTTP/TCP connection records. Look for web or application service processes spawning shells or interpreters, execution of discovery commands, creation of unusual files in web-accessible or temporary directories, new users or SSH authorized keys, modified startup scripts, and outbound connections from the appliance to unfamiliar IP addresses. Because exploitation yields root-level access, absence of logs is not proof of safety; attackers may delete or alter evidence. If the appliance was internet-facing and vulnerable during the active exploitation window, prioritize forensic preservation, compare filesystem state against a known-good build, and rotate secrets even if direct indicators are limited.

• ;id
• ; whoami
• ; uname -a
• ; cat /etc/passwd
• ; curl
• ; wget
• |id
• | whoami
• `id`
• $(id)
• /bin/sh
• /bin/bash
• /bin/nc
• /usr/bin/nc
• /bin/busybox
• /tmp/
• /var/tmp/
• /dev/shm/
• authorized_keys
• /root/.ssh/authorized_keys
• /etc/crontab
• /etc/cron.d/
• /etc/systemd/system/
• chmod +x
• curl http
• wget http
• bash -i
• /dev/tcp/
• nc -e
• ncat -e
• python -c
• perl -e
• socat TCP

What your security team should do

• Immediately identify all Ivanti Standalone Sentry appliances and determine whether any are running versions before R10.5.2, R10.6.2, or R10.7.1.
• Patch affected appliances to R10.5.2, R10.6.2, R10.7.1, or later without delay; this vulnerability is actively exploited and listed in CISA KEV with a 2026-06-14 due date.
• If patching cannot be completed immediately, isolate affected appliances from the internet and restrict access to only required trusted sources until upgraded.
• Treat exposed vulnerable appliances as potentially compromised; begin incident response, preserve logs, and collect forensic images or triage artifacts before rebuilding or making major changes where possible.
• Rotate credentials, API keys, certificates, and secrets stored on, managed by, or proxied through affected Sentry appliances if compromise is suspected or cannot be excluded.
• Hunt for signs of root command execution, web shells, reverse shells, new users, SSH key additions, cron/systemd persistence, unexpected binaries, and anomalous outbound connections from Sentry appliances.
• Review firewall, VPN, mobile access, MDM/UEM, and identity integrations for signs of unauthorized access originating from or enabled by the Sentry appliance.
• Add SIEM detections for suspicious Sentry HTTP requests containing command-injection metacharacters and for appliance processes spawning shells or network utilities.
• After remediation, perform an external exposure review to ensure Sentry management and administrative interfaces are not publicly accessible unless explicitly required and protected.
• Track Ivanti advisories for additional hardening guidance, hotfixes, compromise indicators, and recommended forensic procedures.