CVE-2026-111357: Ivanti Privilege Escalation

Detection Guidance

Detection should combine version inventory, appliance telemetry, authentication records, configuration-integrity monitoring, and network-side investigation. A vulnerable version alone does not prove compromise, while a patched version does not rule out prior exploitation. Preserve relevant logs before rebooting or reimaging a suspected appliance where operationally feasible.

Review administrative and authentication activity beginning in October 2026, with special attention to:

• Unexpected successful logins.
• Authentication-bypass symptoms.
• New or modified local accounts.
• Changes to VPN policies.
• Unusual configuration exports.
• Administrative activity from unfamiliar addresses.
• Unexplained service restarts.
• Files written outside expected appliance locations.
• Unexpected child processes.
• Outbound connections from the appliance to systems that do not normally receive VPN infrastructure traffic.

Technical Notes

The supplied research does not provide a vendor-specific log field, stable indicator, or network signature for this CVE. Do not invent a signature for dsinvoked or DSCache; appliance versions and logging formats can vary. Use a generic correlation query as a starting point and validate field names against the local Ivanti log export:

(index=ivanti OR index=vpn)
(
  ("dsinvoked" OR "DSCache")
  OR ("authentication" AND ("bypass" OR "failed" OR "succeeded"))
  OR ("configuration" AND ("changed" OR "exported" OR "updated"))
)
| stats count min(_time) as first_seen max(_time) as last_seen
  values(src_ip) as source_ips
  values(user) as users
  values(action) as actions
  by host
| where count > 0

The query is a triage aid, not a confirmed CVE detection rule. A stronger detection workflow is to compare appliance configuration and account state against known-good baselines, identify unexpected outbound traffic, and correlate appliance events with perimeter firewall, identity-provider, and endpoint telemetry.

If the appliance supports an integrity-check or internal forensic utility, use Ivanti’s documented procedure rather than manually deleting suspicious files.

For network monitoring, prioritize:

• Unusual outbound sessions from the appliance.
• Administrative access from new geographies or autonomous systems.
• Management traffic initiated by the appliance toward internal servers.
• Authentication activity inconsistent with normal administrative workflows.

There is no reliable CVE-specific network signature in the supplied material, so defenders should avoid treating the absence of a signature match as evidence of safety.

Remediation Steps

Upgrade affected 25.1.x installations to 25.1.1.3 and affected 22.8R2.x installations to 22.8R2.6. The supplied vendor information identifies these as the resolved versions.

Because this CVE is in CISA KEV, prioritize internet-facing appliances and complete remediation by November 2, 2026, consistent with applicable CISA guidance. Maintain a written inventory of appliance identifiers, installed versions, upgrade timestamps, validation results, and any exceptions.

Access to the download or support portal may require an Ivanti login. Confirm the target release and installation sequence in Ivanti’s official advisory and support documentation before making the change.

If a fixed release cannot be applied promptly, follow Ivanti’s documented mitigation instructions. The supplied sources do not provide a complete vendor workaround, so administrators should not substitute an unverified configuration change.

Technical Notes

Use the appliance’s supported upgrade mechanism and Ivanti-provided package rather than a generic operating-system package manager. A command such as apt upgrade or yum update is not an appropriate remediation for Connect Secure.

Record the remediation in a runbook similar to the following:

1. Record the current Ivanti Connect Secure version and appliance identifier.
2. Download the vendor-provided 25.1.1.3 or 22.8R2.6 package from Ivanti's support portal.
3. Verify the package using Ivanti's documented integrity and authenticity checks.
4. Create or validate a recovery configuration backup.
5. Install the package through the supported Connect Secure administration workflow.
6. Confirm the post-upgrade version and service health.
7. Recheck authentication, VPN policy, logging, and administrative access.
8. Preserve pre-upgrade logs if compromise is suspected.

If an appliance is believed to be compromised, do not treat patching alone as incident closure. Isolate or restrict access according to the organization’s incident-response plan, preserve forensic evidence, rotate credentials and secrets that may have been exposed, and investigate lateral movement.

CISA’s KEV guidance calls for forensic triage where applicable. A rebuild or vendor-assisted recovery may be more appropriate than an in-place upgrade when root-level compromise is suspected.

Where a fixed release is temporarily unavailable, reduce exposure by restricting management access, limiting administrative source networks, enforcing stronger upstream access controls, and following Ivanti’s official mitigation instructions. These measures are compensating controls only; they do not remove the vulnerable code or address exploitation that has already occurred.

Incident Response Considerations

Organizations should treat suspected exploitation as a security incident rather than a routine patching event. Prioritize the following actions:

1. Identify all Ivanti Connect Secure appliances and record their exact versions.
2. Determine whether each appliance was internet-facing during the exposure period.
3. Preserve authentication, administrative, configuration, and network logs.
4. Review local accounts, VPN policies, certificates, tokens, and stored credentials.
5. Investigate unusual outbound traffic and administrative access.
6. Rotate credentials and secrets that may have been accessible from the appliance.
7. Check connected identity, endpoint, firewall, and management systems for follow-on activity.
8. Coordinate with Ivanti or an incident-response provider if root-level compromise is suspected.
9. Document remediation, validation, and any remaining exceptions.

A patched appliance may still require credential rotation and broader investigation if it was vulnerable before the upgrade. Conversely, suspicious activity should be evaluated against logs and system baselines rather than attributed automatically to this CVE.