CVE-2026-10523

What it actually does

CVE-2026-10523 is an authentication bypass in Ivanti Standalone Sentry prior to R10.5.2, R10.6.2, and R10.7.1. A remote attacker can bypass intended authentication controls and create arbitrary administrative accounts, resulting in full administrative control of the Sentry appliance. Because Sentry is typically positioned as a gateway/control point for mobile and enterprise access, successful exploitation can expose sensitive configuration data, allow policy manipulation, enable credential or token access depending on deployment, and support further compromise of connected systems.

Why it matters to the business

Successful exploitation can give an external attacker full administrative control over an Ivanti Sentry deployment, potentially disrupting secure mobile access, weakening enforcement policies, exposing sensitive enterprise access configurations, and creating a path into downstream services. The CVSS score is critical and EPSS is elevated, indicating meaningful likelihood of exploitation even though it is not currently listed in CISA KEV and no ransomware use is reported. Organizations using affected versions should treat remediation as urgent because administrative account creation is a high-impact outcome that can quickly lead to operational compromise.

How an attack unfolds

An attacker identifies an internet-accessible or otherwise reachable Ivanti Standalone Sentry instance running a vulnerable release. They send crafted requests to the affected authentication or administrative workflow to bypass normal identity checks. Instead of requiring valid administrative credentials, the vulnerable system permits creation of a new administrator-controlled account. The attacker then logs in using that account and gains full administrative access to the Sentry management interface. From there, they can modify configuration, inspect policies, create persistence through additional accounts, weaken security controls, and potentially pivot toward systems integrated with Sentry.

How to fix it

Upgrade Ivanti Standalone Sentry to a fixed release immediately: R10.5.2, R10.6.2, or R10.7.1 or later, matching the currently deployed major/minor branch. If immediate upgrade is not possible, restrict access to the Sentry administrative interface to trusted management networks or VPN-only access, block direct internet exposure, enforce network-layer allowlists, review all administrative accounts, and remove any unknown or unnecessary accounts. Rotate credentials, API secrets, certificates, and integration tokens if compromise is suspected. Ensure backups are taken before upgrade and verify that high-availability or clustered deployments are upgraded consistently.

How to confirm the fix worked

Confirm the installed Ivanti Standalone Sentry version is R10.5.2, R10.6.2, R10.7.1, or later. Validate from the product management interface and, where available, the appliance CLI or version endpoint. Confirm the administrative interface is not exposed to untrusted networks. Review the complete administrator account list for unauthorized, recently created, disabled-but-present, or unusually named accounts. Verify that no unexpected configuration changes occurred around the suspected exposure window. After patching, attempt to reproduce only in an authorized test environment or rely on vendor-provided validation checks; production testing should avoid exploit-style account creation.

Typical attack path

1. Discover Ivanti Standalone Sentry appliances exposed to the internet or accessible from a compromised network segment.
2. Fingerprint the appliance version or infer vulnerability based on exposed service behavior.
3. Send crafted unauthenticated requests that abuse the authentication bypass condition.
4. Create a new arbitrary administrative account under attacker control.
5. Authenticate to the administrative interface using the newly created account.
6. Modify configuration, create additional persistence, collect sensitive settings, or use Sentry access to support lateral movement into connected services.

How to detect it

Investigate whether the Sentry administrative interface was reachable from untrusted networks during the exposure window. Review Ivanti Sentry administrative audit logs, system logs, web access logs, reverse proxy logs, firewall logs, VPN logs, and identity-provider logs for signs of unauthorized administrator creation or login. Focus on events showing new administrative users, role changes to administrator, successful logins by newly created users, failed or unusual requests to account-management endpoints, and management access from unfamiliar IP addresses or geographies. Compare administrator account creation timestamps against authorized change records. Look for configuration changes after suspicious logins, including policy modifications, certificate changes, new trusted hosts, altered authentication settings, or added service integrations. Because no public exploit artifacts are provided in the input, detection should prioritize behavioral evidence: unexpected admin accounts, anomalous account-creation events without prior authenticated sessions, and management activity from unusual network sources.

• new administrator account created
• admin account created
• administrator created
• user created with administrator role
• role changed to administrator
• successful administrator login
• failed login to admin interface
• configuration changed
• authentication settings changed
• policy modified
• certificate updated
• trusted host added
• Ivanti Standalone Sentry
• /admin
• /mics
• /api
• /login

What your security team should do

• Upgrade all Ivanti Standalone Sentry deployments to R10.5.2, R10.6.2, R10.7.1, or later as a priority.
• Immediately restrict administrative interface access to trusted management IP ranges and remove direct internet exposure.
• Audit all administrative accounts and delete any unknown, recently created, or unnecessary accounts.
• Review logs for unauthenticated account-creation attempts, new administrator creation events, and logins from unusual source IP addresses.
• Rotate administrative credentials and integration secrets if there is any evidence of unauthorized account creation or configuration access.
• Capture and preserve relevant appliance, reverse proxy, VPN, firewall, and identity-provider logs before retention windows expire.
• Monitor vendor advisories for updated indicators, exploit details, and any change in exploitation status or KEV listing.