Ivanti Sentry CVE-2026-10520: Root on Your Edge Gateway, and the Small-Business Patch-Now Playbook

A working exploit for Ivanti Sentry went public on Wednesday, June 10. Inside of a day, the Shadowserver Foundation was scanning the internet and finding that most of the exposed Sentry gateways it could see had already been backdoored. On June 11, CISA added the flaw to its Known Exploited Vulnerabilities catalog and gave federal agencies until June 14 to fix it. That is a three-day clock on a box that, when it falls, hands an attacker root.

The bug is CVE-2026-10520, and it scores a CVSS 10.0, the maximum on the scale. Ivanti Sentry is the appliance that stands between a company's phones and tablets and the email, files, and internal apps behind them; it decides which devices are allowed to reach the corporate backend. An unauthenticated attacker who can talk to its web interface can now run commands on it as root, with no password and no account. A second flaw disclosed the same day, CVE-2026-10523 (CVSS 9.9), lets a low-privilege user create their own administrator account. Either path ends with the attacker owning the gateway.

Why this matters to you, and who can stop reading

Here is the relevance verdict up front, because most security writing skips it. If your company does not run Ivanti Sentry, or its older name MobileIron Sentry, this particular vulnerability is not your emergency. Note the pattern further down and get on with your day. There is no Sentry hiding inside a typical Microsoft 365 or Google Workspace shop.

If you do run Sentry, and plenty of mid-sized companies, school districts, healthcare groups, and government contractors inherited one with a mobile-device-management rollout years ago, then this is the thing you handle before anything else this week. The appliance holds the credentials and session tokens for the systems it brokers. When it is taken, the attacker does not just get one server. They inherit the trusted path that server had into your mail, your file shares, and your line-of-business apps. The access-control layer you bought Sentry to enforce quietly stops enforcing anything, and the attacker can push configuration to your enrolled devices from a position your fleet already trusts.

The harder problem for a smaller organization is that you may not know whether you run it at all. Sentry tends to get deployed once, by a vendor or a long-departed admin, and then forgotten because it works without complaint. That blind spot is the real story of this incident, and we will come back to it.

What the attacker actually sends

The flaw lives in a class called ConfigServiceController, reachable over an unauthenticated POST to /mics/api/v2/sentry/mics-config/handleMessage. The endpoint takes a message parameter and parses it as an internal configuration command. When the command is execute, the values flow through the appliance's own request handler and arrive at a method that runs native operating-system commands. The team at watchTowr Labs, who published the analysis and the proof of concept, showed it by running uname -a on a target with a single request shaped like this:

POST /mics/api/v2/sentry/mics-config/handleMessage HTTP/1.1
Host: sentry.example.com
Content-Type: application/x-www-form-urlencoded

message=execute system /configuration/system/commandexec <commandexec><index>1</index><reqandres>uname -a</reqandres></commandexec>

Swap uname -a for anything else and it runs as root. There is no memory corruption, no timing window, no chained gadget to line up. A text field gets handed to the shell. That is why exploitation began inside of a day: the barrier to entry is reading a blog post and copying a request.

The versions that matter

Ivanti's security advisory lists everything at or below these builds as vulnerable, with the fixes shipped June 9:

• Sentry 10.7.0 and earlier, patched in 10.7.1
• Sentry 10.6.1 and earlier, patched in 10.6.2
• Sentry 10.5.1 and earlier, patched in 10.5.2

The pattern: the edge box nobody is watching

Step back from this one CVE and the shape is familiar. Over the past two years Ivanti's internet-facing products, Connect Secure, the EPMM mobile manager, and now Sentry, have been a recurring on-ramp for both ransomware crews and state-backed groups. The reason is structural. These appliances sit at the perimeter by design, they speak to the most sensitive systems inside, and almost nobody installs an endpoint agent on them. When a Windows server gets popped, your EDR usually screams. When an edge appliance gets popped, the only logs are on the appliance, and the appliance now belongs to the attacker.

That combination of high value, internet reachability, and thin monitoring is why a single public proof of concept turned into widespread compromise within a day. Shadowserver found vulnerable instances and confirmed back doors on a share of them almost at once. Rapid7 told customers to patch outside the normal cycle. The three-day CISA deadline is not bureaucratic theater; it reflects how fast this class of target gets cleaned out once the exploit is in the open.

Why outsourced IT makes this sharper for a small business

A smaller organization often lives one rung further from the problem. The appliance was racked by a managed service provider or a one-time integrator, the maintenance contract lapsed, and the box kept running on whatever build it shipped with. When a CVE like this lands, the larger enterprise has a security team that already knows the appliance exists and owns the patch. The 40-person company has to first establish whether the device is theirs to patch or their provider's, and that phone call can burn the whole three-day window. If you outsource IT, send your provider one question today: is our Sentry patched to a fixed build, and was it reachable from the internet before it was. Get the answer in writing.

Find out whether you are exposed, in that order

Two questions, fast. First: do you have a Sentry at all, and is it reachable from the internet? Second: has anyone already been at it? Check the running build from the appliance console, and check exposure from outside your network rather than trusting the firewall diagram.

# From a host OUTSIDE your network, see whether the vulnerable endpoint answers.
# Any HTTP status here (rather than a refused connection) means it is reachable.
curl -sk -o /dev/null -w "%{http_code}\n" \
  -X POST "https://sentry.example.com/mics/api/v2/sentry/mics-config/handleMessage" \
  --data "message=ping"

# Confirm the build from the Sentry System Manager / CLI. After patching,
# the system version should read 10.5.2, 10.6.2, or 10.7.1 (or later).

Then go through the web and application logs on the appliance for the one request pattern that matters. The exploit leaves a distinctive fingerprint:

# Hunt the access logs for the exploit endpoint.
grep -E "mics-config/handleMessage" /var/log/*/access*.log 2>/dev/null

# The command-injection variant carries this XML structure in the request body:
grep -rEi "execute system .*commandexec|<reqandres>" /var/log 2>/dev/null

Any POST to handleMessage from an address that is not yours, and especially one carrying commandexec or reqandres tags, is the signal to act on. Copy those logs off the box first, before you touch anything else, so you keep evidence an attacker on the appliance can otherwise delete.

If it was reachable, treat it as breached

Because compromise of these gateways ran ahead of the public disclosure, a Sentry that was internet-facing and unpatched at any point between June 10 and the moment you fixed it should be treated as breached until you can prove otherwise. Patching closes the door; it does not evict someone who already walked through. Work the assumption-of-breach checklist in order:

• Patch first to 10.7.1, 10.6.2, or 10.5.2, then pull the appliance off the public internet if it has no business being there.
• Rotate every secret the appliance held: the certificates, the service accounts it used to reach Exchange or your backend, and any API tokens. Stored credentials are what an attacker takes first.
• Hunt the systems Sentry talks to, not just Sentry itself. The whole point of taking the gateway is the trusted path beyond it.
• Rebuild rather than scrub if you find a back door. A root-level implant on an appliance you cannot run real forensics against is not something you clean with any confidence.

This is also the honest case for calling in help. A reimage-and-rotate on a perimeter appliance, run while you are still unsure what the attacker already carried out, is exactly the kind of work where a second set of experienced hands pays for itself.

Patch Sentry today, then go map the appliances you forgot you run

The patch is the easy part, and you should apply it before you finish reading this. The lasting fix is the inventory. Most small and mid-sized organizations cannot name every internet-facing appliance they own, because the VPN concentrator, the mail gateway, the MDM box, and the file-transfer server were each set up once and never revisited. Enumerating exactly those is an attacker's opening move. Spend an afternoon this month building the list, every device with a public address, the version it runs, and the person responsible for patching it, and you turn the next maximum-severity edge bug from a fire drill into a line item.

If you want a hand drawing that map, finding what your business actually exposes to the internet and how an attacker would chain it together is the work we do. Book a session and we will start at your edge.