Root on the gateway: unauthenticated command injection in Ivanti Sentry

Standalone Sentry sits in front of your mobile fleet. It brokers traffic between managed devices and the back-end services those devices reach, it enforces enrollment and posture, and it holds the certificates and configuration that make the whole mobile-device-management picture trustworthy. That is exactly why a pre-authentication remote code execution bug here is worse than the same bug on a general-purpose web server. The gateway is not on the edge of the trust boundary. It is the trust boundary. Verifiable security.

What the number 10.0 is actually telling you

A CVSS 3.1 base score of 10.0 is rare, and the vector for CVE-2026-10520 reads AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Read left to right, it is a checklist of everything you do not want to be true at once. AV:N means the attack comes over the network, so any host that can reach the appliance can attempt it. AC:L means the attack is low-complexity, with no race window or special conditions to line up. PR:N means no privileges are required, so the attacker never authenticates. UI:N means no user has to click anything. S:C is the one people skim past and should not: the scope is changed, meaning the impact escapes the vulnerable component and lands on resources beyond it. And the three impact metrics, confidentiality, integrity, and availability, are all High. A single vector telling you unauthenticated, network-reachable, scope-changing, total loss is the definition of the worst case.

The affected builds are specific. Standalone Sentry before R10.5.2, R10.6.2, and R10.7.1 is vulnerable, and the fixes ship in those same R-releases: R10.5.2, R10.6.2, and R10.7.1. Version is therefore the highest-signal fact you have. A gateway on a listed build, reachable from outside, is not a maybe. The catalog exists because exploitation has been observed.

The mechanism, at defender altitude

The shape of a command injection is always the same sentence: attacker-controlled input crosses a boundary into an OS command without neutralization. Somewhere in the pre-authentication request handling, a value taken straight from the request is used to build a command line that the appliance then runs through a shell. The code assumed that value would be a benign identifier. The shell does not share that assumption. It reads shell metacharacters, a semicolon, a pipe, a subshell, as instructions, not data, and executes whatever the attacker appended.

Two properties turn that from a bug into a catastrophe. First, the vulnerable path is reachable before authentication, so the attacker never needs a credential to get their input to the shell. Second, the service runs as root. Command injection inherits the privilege of the process that runs the command, so injected metacharacters execute as root. There is no privilege-escalation step to chain, no local exploit to stage. The first request that lands is already the highest-privilege request the box can grant.

Conceptual flow only. No weaponized input is shown or needed to understand the exposure.

This is not a novel technique. It continues a pattern the industry has watched repeat on internet-facing management appliances: pre-authentication command execution on the very devices that broker high-trust sessions. The lesson is not that the class is exotic. It is that these boxes keep getting filed under trusted infrastructure and skip the input-validation scrutiny a public web app would never be allowed to skip.

Why the gateway is the worst place to lose

When an attacker owns the mobility gateway, they do not just own a server. They own the arbiter of your enrolled-device trust. From root on Sentry, the reachable prizes are the certificates and profiles that authenticate devices, the configuration that decides what a managed device may reach, and the brokered path into the back-end services behind it. A foothold here is not a foothold at the perimeter. It is a foothold at the center, with a signed path outward to every device that trusts the gateway. That is what the scope-changed metric is describing in plain terms.

The gateway is not on the edge of the trust boundary. It is the trust boundary. Root here is a signed path to every device that trusts it.

How to recognize your exposure

You can assess this risk without sending a single malicious byte, because the exposure is determined by three readable facts.

How Celvex catches this

The uncomfortable part of a 10.0 on an appliance is that there is no clever mitigation that substitutes for the patch. You cannot input-validate your way around a vendor code path from the outside, and a web application firewall in front of a pre-auth root injection is a speed bump, not a fix. The two levers that actually move risk are the upgrade and the exposure. Get onto a fixed R-release, and take the management plane off the open internet so the pre-authentication surface a stranger can reach shrinks toward zero.

Verifiable security. Find it. Prove it. Fix it. Verify the fix held. That is what we ship.