Ivanti published an advisory on 9 June 2026 for two critical flaws in Ivanti Sentry, the gateway that sits between mobile devices and internal resources. The first, CVE-2026-10520, is an OS command injection that lets an unauthenticated attacker run commands as root. Ivanti said at disclosure that it knew of no exploitation.
That changed fast. watchTowr published a technical analysis and a public proof of concept on 10 June, and CISA added CVE-2026-10520 to the Known Exploited Vulnerabilities catalog on 11 June.
What's affected
Per Rapid7's analysis, both CVEs affect Ivanti Sentry 10.7.0 and below, 10.6.1 and below, and 10.5.1 and below. Fixed releases are 10.7.1, 10.6.2 and 10.5.2.
- CVE-2026-10520: CWE-78, CVSS 10.0. The vulnerable code is the
ConfigServiceControllerclass, reached by a POST to/mics/api/v2/sentry/mics-config/handleMessage. - CVE-2026-10523: an authentication bypass through an alternate path, CVSS 9.9, that Rapid7 says lets an unauthenticated attacker create administrative accounts. Rapid7 notes its CVSS vector shows low privileges required, which does not match that description, so check the vendor advisory for the exact scoring.
CISA's listing covers CVE-2026-10520. I found no KEV entry for CVE-2026-10523 in the catalog data I checked.
How to check if you're exposed
Confirm the Sentry version in the admin console, and compare it to the three fixed builds above. Then look for the request path in your reverse proxy and appliance logs:
grep '/mics/api/v2/sentry/mics-config/handleMessage' access.log*
Rapid7 notes that the public proof of concept uses a python-requests/2.33.0 User-Agent and a message parameter carrying a commandexec payload, though an attacker can change both. Also review the administrator account list for names nobody created.
What to do now
- Apply the fixed release for your branch outside the normal change window.
- Make sure the management interface is not reachable from the internet. If it was, assume compromise.
- Compare the admin account list against your records and remove unknown administrators.
- On any appliance that was exposed before patching, review outbound connections and processes started by root, and rebuild it if anything looks wrong.
- Rotate credentials and certificates stored on exposed appliances.
How this could have been avoided
- Keep management interfaces off the internet. The vulnerable endpoint belongs to the management service. Reachability from outside is what turned a bug into a breach.
- Shorten patch windows for edge devices. Exploitation began a day after the proof of concept. A rule of "internet facing appliance, critical flaw, patch within 24 hours" fits this timeline.
- Do not build shell commands from request data. The root cause is a request parameter reaching a command executor. Pass arguments as arrays or use an allowlist of fixed actions.
- Run appliance services without root. Root meant one request gave full control.
Why it matters
Gateways in front of your mobile and internal estate are attractive because they hold credentials and sit at a trust boundary. The gap between a vendor advisory and a working public exploit is now measured in a day. Inventory comes first: you cannot patch an appliance you forgot you own.
Try it yourself
Write down every internet facing appliance in your environment with its version and its management address, then check that list against vendor advisories each Tuesday.
Click through it at your own pace, or open it full screen.
Quick check
Which Sentry releases contain the fix?
10.7.1, 10.6.2 and 10.5.2, depending on your branch.
How long did exploitation take after disclosure?
CISA listed CVE-2026-10520 two days after Ivanti's 9 June advisory, a day after the public proof of concept appeared.
