CVE-2026-104935: Ivanti Connect Secure Auth Bypass Exploitation — Detection, Patch Verification, and Remediation Guide

Edge VPN appliances remain one of the most reliably targeted asset classes in enterprise networks, and Ivanti Connect Secure (ICS) has once again proven why. CVE-2026-104935 — a high-severity authentication bypass chained with a critical code execution flaw — is being actively exploited against ICS gateways that received only a partial fix in July's patch cycle. The uncomfortable lesson here is one I have seen play out in incident response engagements more times than I care to count: a patch applied is not always a vulnerability closed.

What makes this story particularly important for defenders is the vendor-side failure mode. Ivanti's July update addressed the code execution component of the flaw but incompletely accounted for the authentication bypass path, leaving a residual attack surface that threat actors quickly identified and weaponized. Organizations that dutifully patched in July may still be exposed — and worse, may believe they are not.

If you operate Ivanti Connect Secure gateways, this post walks you through what is actually at risk, how to detect exploitation and post-exploitation behavior, how to verify your patch state with confidence, and the containment steps you should execute if your appliances sat unpatched (or partially patched) for any meaningful window.

Technical Analysis

Affected Products and Versions

The vulnerability affects Ivanti Connect Secure (ICS) gateways — the SSL VPN platform formerly known as Pulse Connect Secure — across supported release trains. Appliances running versions prior to the July cumulative update are fully vulnerable; appliances that received the July update are protected against direct code execution but, per the reporting, retain an exploitable authentication bypass surface that permits access to restricted administrative and portal-facing functionality. Confirm your exact build against the vendor advisory, because the distinction between "patched" and "fully patched" is the entire story here.

Key exposure factors:

• Internet-facing ICS portals: The authentication bypass is remotely exploitable against the appliance's web interface with no valid credentials required.
• Appliances that applied only the July update: Do not assume remediation completeness. Treat these as suspect until verified against the follow-on fix.
• End-of-support or lagging versions: Appliances outside the vendor's supported patch cadence should be considered fully exposed and prioritized for replacement or isolation.

How the Attack Chain Works (Defender's View)

The reported exploitation chain follows a two-stage pattern that has become standard for edge appliance intrusions:

1. Authentication bypass (CVE-2026-104935, primary stage): The attacker sends crafted HTTP(S) requests to the ICS web interface that manipulate path normalization or session handling logic, causing the appliance to treat unauthenticated requests as authenticated. This grants access to functionality that should be gated behind login — including administrative or configuration endpoints.

2. Code execution (secondary stage): Once past the authentication boundary, the attacker reaches the code execution primitive, allowing arbitrary command execution on the appliance itself — typically running as a privileged process, since ICS management interfaces execute with elevated rights.

Post-exploitation tradecraft for ICS compromise follows the well-established edge-device playbook, and your detections should be tuned for it:

• Webshell deployment: Dropped into the appliance's web root (commonly under /home/webserver/htdocs/ or theme/component directories) to provide durable access.
• Persistence via legitimate tooling: Modification of appliance configuration, certificate stores, or scheduled tasks rather than obvious malware.
• Living-off-the-land execution: Use of native binaries present on the ICS Linux-based OS (curl, wget, python, shell interpreters) for staging and exfiltration.
• Credential harvesting: Extraction of cached VPN session credentials and local user databases for lateral movement into the internal network.
• Log tampering: Clearing or truncating appliance event logs — treat gaps in ICS logging as an intrusion indicator, not an operational anomaly.

Exploitation Status

• Confirmed active exploitation: Threat actors are capitalizing on the residual attack surface left by the partial July fix. This is not theoretical.
• Patching gap risk: The window between the July partial patch and the complete fix represents a period where organizations believed themselves protected while remaining exploitable — a classic and dangerous assurance gap.
• KEV posture: Given confirmed in-the-wild abuse of an internet-facing, unauthenticated attack path, expect this vulnerability class to draw CISA KEV attention with aggressive federal remediation deadlines. Do not wait for a KEV listing to act; treat it as if it were already there.

Detection & Response

Edge appliances are detection-poor environments by default — you cannot run an EDR agent on an ICS gateway. That means your detection strategy must combine appliance log telemetry forwarded to your SIEM (which is hunt-able via Syslog/CEF ingestion in Sentinel) with network and internal endpoint visibility that catches the attacker after they pivot off the appliance. If your ICS logs are not flowing to your SIEM today, that is finding zero in your next architecture review.

Sigma Rules

The following rules target the internal-side behaviors that ICS compromise produces. The first catches webshell-style execution children spawned from web server processes (applicable where ICS-adjacent Windows infrastructure or mirrored logs are instrumented); the second detects anomalous authentication and post-auth command activity observable in forwarded appliance logs; the third hunts VPN-to-internal lateral movement that follows credential theft from a compromised gateway.

---
title: Web Server Process Spawning Command Shell — Possible ICS-Style Webshell Execution
id: 8f2b1c45-3d6e-4a7b-9c0d-2e4f6a8b1c3d
status: experimental
description: Detects web server or CGI worker processes spawning command interpreters, consistent with webshell execution on a compromised VPN or web appliance. Prioritized for hosts adjacent to Ivanti Connect Secure gateways.
references:
  - https://attack.mitre.org/techniques/T1505/003/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.initial_access
  - attack.t1505.003
  - attack.t1190
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\httpd.exe'
      - '\nginx.exe'
      - '\w3wp.exe'
      - '\php-cgi.exe'
      - '\node.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\curl.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate web applications invoking system commands (CMS plugins, backup scripts)
  - Application deployment pipelines
level: high
---
title: Ivanti ICS Suspicious Post-Authentication Command Execution in Appliance Logs
id: 4a7d9e12-5b8c-4f3a-8d1e-6c2a9b4d7e5f
status: experimental
description: Detects strings in forwarded Ivanti Connect Secure Syslog/CEF events indicative of command execution, shell access, or webshell staging on the appliance OS.
references:
  - https://attack.mitre.org/techniques/T1059/
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.command_and_control
  - attack.t1059
  - attack.t1105
logsource:
  product: linux
  service: syslog
detection:
  selection_source:
    HostName|contains:
      - 'ivanti'
      - 'connect-secure'
      - 'ics'
      - 'vpn'
  selection_keywords:
    Message|contains:
      - 'cmd='
      - '/bin/sh'
      - '/bin/bash'
      - 'wget http'
      - 'curl http'
      - 'python -c'
      - 'base64 -d'
      - 'chmod +x'
      - 'htdocs'
      - '/tmp/'
  condition: selection_source and selection_keywords
falsepositives:
  - Vendor support diagnostics executed by administrators
  - Scripted appliance health checks
level: high
---
title: VPN-Source Lateral Movement to Internal Systems via SMB or RDP
id: 2c6e8a34-9d1b-4f5c-a7e3-8b6d4c2f9a1e
status: experimental
description: Detects authentication and administrative protocol connections originating from the VPN address pool toward internal servers, consistent with post-compromise pivoting from a breached Ivanti Connect Secure gateway using harvested credentials.
references:
  - https://attack.mitre.org/techniques/T1021/
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.lateral_movement
  - attack.t1021.001
  - attack.t1021.002
  - attack.t1078
logsource:
  category: network_connection
  product: windows
detection:
  selection_port:
    DestinationPort:
      - 445
      - 3389
      - 5985
      - 5986
  filter_rfc1918_src:
    SourceIp|startswith:
      - '10.'
      - '172.16.'
      - '192.168.'
  filter_workstation_dst:
    DestinationHostname|contains:
      - 'desktop'
      - 'laptop'
      - 'wkstn'
  condition: selection_port and filter_rfc1918_src and not filter_workstation_dst
falsepositives:
  - Helpdesk remote administration from VPN segments
  - Vulnerability scanners in VPN pool ranges
level: medium

Note on tuning: scope rule three by replacing the RFC1918 source filter with your actual ICS-assigned VPN address pool subnets — that single change eliminates most noise and makes this a genuinely high-fidelity hunt.

KQL Hunt — Microsoft Sentinel / Defender

This query hunts forwarded ICS Syslog/CEF events for exploitation indicators: unauthenticated request patterns hitting administrative paths, command execution strings, webshell writes, and log-clearing activity. It assumes your ICS appliances forward logs to Sentinel via a Syslog/CEF collector — which they should.

let SuspiciousPaths = dynamic(["admin", "dana-na", "dana/html5acc", "htdocs", "/tmp/"]);
let SuspiciousCmds = dynamic(["/bin/sh", "/bin/bash", "wget http", "curl http", "python -c", "base64 -d", "chmod +x", "cmd="]);
union withsource=tableName Syslog, CommonSecurityLog
| where TimeGenerated > ago(14d)
| extend MessageText = tostring(coalesce(SyslogMessage, Message))
| where MessageText has_any (SuspiciousCmds)
   or (MessageText has_any (SuspiciousPaths) and MessageText has "POST")
   or (MessageText has_any ("log cleared", "log deleted", "audit", "events cleared"))
| project TimeGenerated, tableName, Computer, SourceIP = coalesce(SourceIP, column_ifexists("SourceIP", "")), MessageText, Severity
| sort by TimeGenerated desc

A complementary internal-side hunt for pivots originating from VPN-assigned source addresses:

// Hunt for lateral movement sourced from the ICS VPN address pool
let VpnPoolCidr = "10.100.0.0/16";  // REPLACE with your ICS-assigned VPN pool
let Lookback = 14d;
DeviceNetworkEvents
| where TimeGenerated > ago(Lookback)
| extend SrcIp = tostring(column_ifexists("LocalIP", ""))
| union (
    SecurityEvent
    | where TimeGenerated > ago(Lookback)
    | where EventID == 4624 and LogonType in (3, 10)
    | extend SrcIp = IpAddress
)
| where ipv4_is_in_range(SrcIp, VpnPoolCidr)
| where isnotempty(SrcIp)
| summarize ConnectionCount = count(), DistinctTargets = dcount(tostring(coalesce(RemoteIP, Computer))), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SrcIp
| where DistinctTargets > 5  // Fan-out behavior: one VPN session touching many internal hosts
| sort by DistinctTargets desc

Velociraptor VQL Hunt

Because the ICS appliance itself cannot host Velociraptor, this artifact targets internal endpoints for evidence of the post-compromise phase: processes spawned from atypical parent chains and network connections back to VPN-pool source addresses, which often indicate an attacker operating through harvested VPN sessions. Deploy against server segments reachable from the VPN.

-- Hunt for suspicious process execution and VPN-origin network connections
-- consistent with post-ICS-compromise lateral movement
LET suspicious_procs = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(powershell.*-enc|certutil.*-decode|bitsadmin.*/transfer|curl.*http|wget.*http)'
   OR (Name =~ '(cmd|powershell|pwsh)\\.exe' AND Username =~ 'SYSTEM')

LET vpn_connections = SELECT Pid, Name, Laddr, Raddr, Status
FROM netstat()
WHERE Status = 'ESTABLISHED'
  AND Raddr.IP =~ '^(10\\.100\\.|192\\.168\\.10\\.)'  // REPLACE with your VPN pool ranges
  AND Laddr.Port =~ '(445|3389|5985|5986|22)$'

SELECT 'SuspiciousProcess' AS FindingType, Pid, Name, CommandLine, Username, CreateTime AS Timestamp
FROM suspicious_procs
UNION ALL
SELECT 'VpnOriginConnection' AS FindingType, Pid, Name, Laddr.String AS Detail, Raddr.String AS Username, now() AS Timestamp
FROM vpn_connections

Remediation & Verification Script

The single most important action right now is verifying your true patch state — not what your change tickets say, but what the appliances report. The following Bash script enumerates ICS appliances, queries their version endpoints, flags appliances running pre-complete-fix builds, and audits for common webshell artifacts if you have shell/REST API access to the appliance. Run it from a management host with network reachability to your ICS admin interfaces.

#!/bin/bash
# ICS Patch Verification and Compromise Audit — CVE-2026-104935
# Usage: ./ics_verify.sh appliance_list.txt
# appliance_list.txt: one appliance IP/FQDN per line

APPLIANCES="$1"
REPORT="ics_audit_$(date +%Y%m%d).txt"
# REPLACE with the minimum build that includes the COMPLETE fix (not the July partial)
MIN_SAFE_BUILD="22.7R2.6"

echo "=== Ivanti ICS Patch State & Compromise Audit ===" | tee "$REPORT"
echo "Target minimum safe build: $MIN_SAFE_BUILD" | tee -a "$REPORT"

while read -r host; do
  [ -z "$host" ] && continue
  echo "" | tee -a "$REPORT"
  echo "--- Checking $host ---" | tee -a "$REPORT"

  # Query the appliance admin REST API for system version info
  VERSION=$(curl -sk --connect-timeout 10 \
    "https://${host}/api/v1/system/version" 2>/dev/null)
  echo "Version response: $VERSION" | tee -a "$REPORT"

  if echo "$VERSION" | grep -q "$MIN_SAFE_BUILD"; then
    echo "[OK] $host reports complete-fix build" | tee -a "$REPORT"
  else
    echo "[ALERT] $host may be running a pre-complete-fix or partial (July-only) build — verify against vendor advisory" | tee -a "$REPORT"
  fi

  # Audit web root for recently modified or unexpected files (webshell indicator)
  echo "[+] Scanning for recently modified web-root files (7-day window)..." | tee -a "$REPORT"
  ssh -o ConnectTimeout=10 admin@"$host" \
    "find /home/webserver/htdocs -type f -mtime -7 -ls 2>/dev/null" 2>/dev/null | tee -a "$REPORT"

  # Check for unexpected listeners spawned outside normal appliance services
  echo "[+] Enumerating listening services..." | tee -a "$REPORT"
  ssh -o ConnectTimeout=10 admin@"$host" \
    "netstat -tlnp 2>/dev/null" 2>/dev/null | tee -a "$REPORT"

done < "$APPLIANCES"

echo "" | tee -a "$REPORT"
echo "=== Audit complete. Review all [ALERT] entries against the vendor advisory. ===" | tee -a "$REPORT"

If you do not have SSH access enabled on the appliances (and you generally should not), substitute the SSH blocks with the ICS Integrity Checker Tool (ICT) output pulled via the admin console — and treat any ICT anomaly as an IR trigger, not a maintenance ticket.

Remediation

Execute these steps in order. Speed matters — this is an actively exploited, unauthenticated, internet-facing attack path.

1. Verify the complete fix, not the July partial. Pull each appliance's exact build number and compare it against the vendor's follow-on advisory that closes the authentication bypass component of CVE-2026-104935. Appliances that received only the July update remain partially exposed. Pull advisories directly from Ivanti's security advisory portal (https://www.ivanti.com/blog/security-update — search the CVE) and the associated Dark Reading coverage at https://www.darkreading.com/vulnerabilities-threats/ivanti-ics-zero-day-attacks-vendor-patching for exploitation context.

2. Assume compromise for any appliance exposed during the gap window. If your ICS gateways were internet-reachable between the July partial patch and the complete fix, patching alone is insufficient — threat actors had a window to establish persistence that survives reboots and upgrades. Run the vendor's Integrity Checker Tool, review admin and event logs for anomalies (including log gaps), audit local user accounts and certificate stores for unauthorized additions, and inspect the web root for unexpected files.

3. Factory-reset and rebuild if integrity checks fail or logs are missing. For edge appliances with confirmed or strongly suspected compromise, rebuilding from a known-good image with fresh credentials and certificates is the only defensible recovery posture. Rotating credentials alone leaves webshells and config-level persistence intact.

4. Rotate everything the appliance touches. This includes VPN user credentials, service accounts, RADIUS/LDAP bind accounts, appliance admin credentials, API tokens, and any certificates or keys stored on the gateway. Assume credential material on a compromised VPN concentrator is burned.

5. Reduce the attack surface permanently. Restrict admin interface access to a dedicated management network (never internet-exposed), enforce MFA on all VPN access, segment VPN-assigned address pools so they cannot reach server management interfaces directly, and disable unused portal features and file-browsing components.

6. Fix the telemetry gap. Forward ICS Syslog/CEF events to your SIEM with a minimum 12-month retention. Every ICS incident response I have worked has been made slower and more expensive by missing appliance logs. This is a prerequisite for the detection content above.

7. Track CISA KEV and vendor deadlines. Monitor https://www.cisa.gov/known-exploited-vulnerabilities-catalog for any KEV listing tied to this campaign — KEV entries carry binding remediation deadlines for federal agencies and are the clearest public prioritization signal for everyone else.

8. Update your patch assurance process. The core lesson of CVE-2026-104935 is that "patched" must mean verified against the complete fix, not "we ran the July update." Build post-patch validation — version checks, exploit-path retesting, and vendor advisory follow-up — into your vulnerability management SLA for all internet-facing appliances.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub