CVE-2026-104935: Ivanti Authentication Bypass

Detection Guidance

Start with asset and exposure validation. Confirm every ICS appliance’s running release, external interfaces, management exposure, administrative access paths, and recent configuration changes. Review reverse-proxy, firewall, VPN, identity-provider, and network-flow telemetry for unexpected requests to the appliance and unusual connections originating from it.

Do not rely solely on the Ivanti Integrity Checker Tool. Available reporting indicates that attacker commands may execute in memory, limiting the value of a clean integrity result. Treat a clean check as one data point and combine it with forensic review and historical telemetry.

For teams formalizing application-security coverage around exposed services, the DAST glossary provides useful background on dynamic application security testing. DAST findings should complement—not replace—appliance telemetry and incident-response investigation.

Technical Notes

The following generic SIEM query is a starting point for locating suspicious activity around affected appliances. Field names must be adapted to the organization’s logging platform:

device_product="Ivanti Connect Secure"
| where timestamp between (patch_window_start .. now())
| where event_type in ("authentication", "admin_action", "command", "configuration_change")
| where outcome in ("success", "allowed")
| summarize count(), values(source_ip), values(user), values(action)
  by bin(timestamp, 5m), destination_ip
| order by timestamp asc

Prioritize events involving previously unseen source addresses, successful administrative actions without a corresponding change ticket, new or modified accounts, unexpected configuration exports, and outbound connections from the appliance to unfamiliar internet hosts. Review firewall and proxy logs for connections from the ICS management or appliance addresses to internal systems that do not normally communicate with the gateway.

A practical network review should search for:

# Pseudocode for a flow-detection rule
source_asset IN (ICS_APPLIANCE_ASSETS)
AND destination NOT IN (APPROVED_IDENTITY_AND_MANAGEMENT_SERVICES)
AND bytes_out > BASELINE
AND first_seen(destination, 30 days)

This is behavioral guidance, not a CVE-specific signature. The available source material does not provide a validated packet signature or reliable exploit URI. Generic requests, HTTP status codes, or a clean integrity scan cannot prove either compromise or innocence.

Remediation Steps

Upgrade each affected appliance to the resolved version for its branch:

• ICS 25.1.1.1 and earlier: upgrade to 25.1.1.2.
• ICS 25.1.2.2 and earlier: upgrade to 25.1.3.0 or 25.1.3.1, as appropriate for the platform and Ivanti’s release guidance.
• ICS 22.8R2.4 and earlier: upgrade to 22.8R2.5.
• ICS 22.7R2.14 and earlier: Ivanti identifies these versions as not affected, but administrators should still validate lifecycle and security status.

Ivanti provides the resolved releases through its download and licensing channels. Use the vendor-supported upgrade workflow for the appliance rather than modifying system files or installing an unapproved package. Confirm the post-upgrade version, configuration integrity, cluster or high-availability status, authentication integrations, and remote-access functionality.

Technical Notes

If an emergency upgrade cannot be completed immediately, apply a temporary exposure-reduction control at the perimeter. For example, on a separately managed Linux firewall, restrict HTTPS access to approved source networks while preserving only required administrative and remote-access paths:

# Example only: run on a separately managed perimeter firewall,
# not in the Ivanti appliance shell.
nft add rule inet filter forward ip daddr <ICS_IP> tcp dport 443 \
    ip saddr != { <APPROVED_VPN_NET>, <ADMIN_NET> } drop

Replace the placeholders with approved networks, test the rule in a maintenance window, and ensure that emergency access and monitoring remain available. This is a compensating control, not a patch. If the appliance cannot be patched or adequately isolated, follow applicable CISA and organizational guidance, including evaluating whether to discontinue use of the exposed product.

After upgrading, investigate for prior compromise. Preserve relevant logs before rotation, inspect authentication and administrative events, review outbound network activity, compare configuration and account state with known-good baselines, and examine connected systems for lateral movement. If compromise is suspected, isolate the appliance according to the incident-response plan and coordinate with Ivanti and CISA guidance. Do not return a potentially compromised appliance to service solely because the Integrity Checker Tool reports no issue.

When response work requires creating or rotating credentials, use an organization-approved password manager and enforce unique credentials and multifactor authentication. Teams managing individual administrator accounts may also consider a service such as 1Password, subject to organizational procurement and security review.

For recovery planning, maintain tested, offline or otherwise protected backups of critical configurations and connected systems. Backups do not remediate the vulnerability, but they can reduce recovery time if investigation identifies unauthorized changes or broader compromise.