Back to Blog
2026-07-10

Ivanti Sentry CVE-2026-10520 and CVE-2026-10523: What Defenders Should Do

Ivanti Sentry CVE-2026-10520 and CVE-2026-10523: What Defenders Should Do

Ivanti disclosed two critical vulnerabilities in Sentry in June 2026. One allows unauthenticated root-level remote code execution; the other allows an unauthenticated attacker to create administrative accounts. CISA added the remote-code-execution flaw to its Known Exploited Vulnerabilities catalog, so exposed appliances should be treated as an incident-response priority—not a routine maintenance item.

This guide sticks to facts published by Ivanti, NVD, and CISA. It deliberately avoids unverified endpoint names, exploit payloads, and log indicators.

What the two CVEs allow

CVE-2026-10520: unauthenticated root-level command execution

CVE-2026-10520 is an OS command injection vulnerability. Ivanti's CVE record says a remote unauthenticated user can achieve root-level remote code execution. Ivanti assigned a CVSS 3.1 base score of 10.0.

CISA added CVE-2026-10520 to the Known Exploited Vulnerabilities catalog on June 11, 2026. CISA also classifies the activity as active exploitation and the vulnerability as automatable, with total technical impact.

CVE-2026-10523: unauthenticated administrative access

CVE-2026-10523 is an authentication bypass. Ivanti's CVE record says a remote unauthenticated attacker can create arbitrary administrative accounts and obtain full administrative access.

Ivanti scores the issue 9.9, while NVD's current assessment scores it 9.8. The operational conclusion is the same: it is critical and requires prompt remediation. Unlike CVE-2026-10520, CISA's current record does not identify active exploitation of CVE-2026-10523.

Affected and fixed releases

Ivanti identifies these releases as unaffected:

  • Sentry R10.5.2
  • Sentry R10.6.2
  • Sentry R10.7.1

NVD lists earlier releases in the affected branches as vulnerable. Do not substitute unrelated release numbers or assume that a similarly named Ivanti product uses the same patch matrix. Confirm the installed Sentry release through your normal administrative inventory and follow Ivanti's advisory for the exact upgrade path.

Defender response checklist

  1. Identify every Sentry appliance. Include standby, disaster-recovery, lab, and externally managed instances.
  2. Confirm the installed release. Compare it with Ivanti's current advisory and upgrade to the applicable fixed release.
  3. Reduce exposure while remediating. Restrict management and appliance access to trusted networks where your architecture permits it. Do not treat a WAF as a substitute for the vendor update.
  4. Preserve evidence before making broad changes. Capture relevant system, authentication, administrator, and network telemetry according to your incident-response process.
  5. Review administrative accounts and access changes. Investigate accounts or configuration changes that cannot be tied to an approved action.
  6. Hunt for compromise using authoritative guidance. Use Ivanti's advisory and CISA's required-action and forensic-triage guidance. Avoid relying on invented URL paths or generic indicators presented as product-specific evidence.
  7. Rotate credentials based on evidence and exposure. Prioritize credentials accessible to the appliance or observed in suspicious activity. Coordinate certificate and secret rotation so it does not destroy evidence or interrupt recovery.
  8. Validate after remediation. Recheck version inventory, external exposure, administrative accounts, and monitoring coverage.

What not to assume

  • Do not assume every internet-facing appliance is compromised solely because it was vulnerable; use incident-response evidence to determine scope.
  • Do not assume patching removes persistence or reverses unauthorized changes.
  • Do not use undocumented API paths or shell commands from secondary articles to test production appliances.
  • Do not expose management interfaces merely to run a remote scanner.

Why this matters

Sentry sits on a sensitive trust boundary. A root-level remote-code-execution path and an administrative-account bypass can affect far more than the appliance itself. The safest sequence is to establish inventory, preserve evidence, remediate with the vendor-supported release, and investigate using authoritative guidance.

Inspect JWTs Without Sending Them to a Server

Use OpsecForge's client-side JWT decoder to inspect token structure locally in your browser. Never paste live production credentials into a tool you do not control.

Open JWT Decoder →

Primary sources

Share this: