When CISA adds a vulnerability to its Known Exploited Vulnerabilities Catalog, you're already behind. CVE-2026-104935, affecting Ivanti Connect Secure versions 25.1.1.1 and prior, 25.1.2.2 and prior, and 22.8R2.4 and prior, shows why your vulnerability management program needs procedures that assume compromise, not just patching timelines.
Scope
This guide covers immediate response procedures for zero-day authentication bypass vulnerabilities in network appliances, using CVE-2026-104935 as a reference case. You'll find specific guidance for:
- Organizations running affected Ivanti Connect Secure versions
- Teams conducting forensic analysis when traditional detection tools fail
- Security engineers building response playbooks for memory-resident attacks
- Teams managing end-of-life transition planning (version 22.8 reaches end of life Jan. 31, 2027)
Key Concepts
Memory-resident exploitation: Threat actors execute commands directly in volatile memory, leaving minimal filesystem artifacts. Ivanti's Integrity Checker Tool won't detect this activity because the malicious code never touches disk.
Authentication bypass: CVE-2026-104935 allows remote, unauthenticated execution of arbitrary commands. The attacker doesn't need credentials to start; they steal them after gaining access.
Factory reset vs. patch-in-place: When you suspect compromise through a zero-day, patching alone doesn't remove persistence mechanisms. You're rebuilding trust in the appliance itself.
Requirements Breakdown
Immediate Actions (Day 0)
Backup configuration
Before you touch anything, create a complete backup of your appliance configuration. This isn't disaster recovery theater; you'll need this exact configuration to restore service after the factory reset. Reference Ivanti's backup procedures for binary configuration archiving.
Assess compromise likelihood
Don't wait for proof. If you're running an affected version and it's internet-facing, assume reconnaissance occurred. CISA added CVE-2026-104935 to the KEV Catalog on Oct. 13, 2026, meaning active exploitation is confirmed.
Conduct memory forensics
Network forensics alone won't cut it. You need memory dumps from running appliances to identify in-memory command execution. Your standard SIEM queries looking for file modifications will miss this entirely.
Recovery Procedure (Days 1-2)
Factory reset and upgrade
For physical appliances: factory reset, then upgrade to the latest version. For cloud and virtual systems: rebuild the virtual instance from scratch, then upgrade. Don't restore from a snapshot taken during the exploitation window.
Restore configuration
Apply the backup you created in step one. This is where you validate that your backup procedure actually works under pressure.
Credential rotation
Reset every password: domain accounts, administrator accounts, local accounts. Revoke and reissue all stored certificates. Reset API keys and license server credentials. Threat actors conducting credential theft through CVE-2026-104935 are targeting exactly these authentication artifacts.
Verification (Day 3+)
Monitor for re-exploitation attempts
Patch the vulnerability, but watch for behavioral indicators that attackers are attempting to regain access using stolen credentials. Your upgraded appliance is secure; your Active Directory might not be.
Document timeline
Record when you discovered the vulnerability, when you patched, what forensic evidence you collected. If you're subject to breach notification requirements under the General Data Protection Regulation or state laws, this timeline determines your 72-Hour Notification Requirement clock.
Implementation Guidance
When Traditional Detection Fails
Your EDR solution isn't running on your VPN appliance. Your file integrity monitoring doesn't catch in-memory execution. Here's what works:
Memory acquisition: Use tools that can capture volatile memory from running appliances. You're looking for command strings, credential harvesting activity, and data staging operations that never touch disk.
Network behavior analysis: Even if the exploit runs in memory, data exfiltration shows up in network flows. Look for unusual outbound connections, especially to infrastructure not associated with your organization.
Log correlation: The appliance may not log the exploit itself, but it will log authentication events that follow. Correlate credential use patterns across systems to identify stolen credentials in active use.
End-of-Life Planning
Version 22.8 reaches end of life Jan. 31, 2027. That gives you a deadline, but zero-day exploitation gives you urgency. Your upgrade planning should account for:
Compatibility testing: Review the Ivanti Connect Secure 25.x Upgrade and Migration Compatibility Guide before you're in crisis mode. Know which hardware supports the new version and which requires replacement.
Maintenance windows: You can't factory reset your VPN appliance during business hours without impact. Plan the downtime, communicate it, and have rollback procedures ready.
Configuration drift: The longer you run an older version, the more your configuration diverges from current security practices. Use this forced upgrade to audit your security settings, not just replicate old configurations.
Common Pitfalls
Assuming patch-in-place is sufficient: If threat actors already established persistence through CVE-2026-104935, patching doesn't remove their access. Factory reset eliminates persistence mechanisms you haven't discovered yet.
Skipping credential rotation: Resetting the appliance but leaving domain credentials unchanged means attackers can use stolen credentials to compromise other systems. The vulnerability was in the VPN appliance; the exposure is enterprise-wide.
Relying on vendor detection tools: Ivanti's Integrity Checker Tool explicitly won't detect this exploitation. Don't treat "tool found nothing" as evidence of safety.
Delaying end-of-life migrations: Version 22.8 has a published end-of-life date. Waiting until Jan. 31, 2027 means you're managing this transition under time pressure instead of on your schedule.
Quick Reference
| Phase | Action | Tool/Reference |
|---|---|---|
| Pre-Reset | Create configuration backup | Ivanti binary configuration archiving |
| Pre-Reset | Conduct memory forensics | Memory acquisition tools |
| Pre-Reset | Document current state | Incident response log |
| Reset | Factory reset (physical) or rebuild (virtual) | Ivanti recovery procedures |
| Reset | Upgrade to latest version | Ivanti security advisory |
| Post-Reset | Restore configuration | Backup from step 1 |
| Post-Reset | Reset all passwords and certificates | Identity management system |
| Post-Reset | Reset API keys and credentials | Application inventory |
| Verification | Monitor for credential misuse | SIEM, authentication logs |
| Verification | Review network behavior | Network monitoring tools |
| Compliance | Document timeline | Incident response documentation |
Your vulnerability management program should assume that some vulnerabilities will be exploited before you patch them. That's not pessimism; it's why CISA maintains a KEV Catalog. Build your procedures accordingly.
