VPN Attacks in 2026: Fortinet, Ivanti, Cisco — Why Passwords Are Not Enough

Posted By Anna on Jul 29, 2026 | 0 comments

The three most widely deployed enterprise VPN platforms of the last decade — Fortinet FortiGate, Ivanti Connect Secure, and Cisco ASA — have together produced dozens of critical, actively exploited vulnerabilities between 2022 and 2026. Every major incident response firm has documented the campaigns. CISA has issued emergency directives. Patches have been released.

And attackers are still getting in.

Not always through new zero-days. Often through credentials. Valid usernames and passwords, obtained from phishing campaigns, leaked configuration files, or breach databases, used against VPN endpoints that accept them without a second factor. The vulnerability patches matter. But they don’t solve the credential problem — and the credential problem is where most of the actual intrusions happen.

A Brief Timeline of Major VPN Incidents: Fortinet, Ivanti, and Cisco

The scale of VPN exploitation in 2022–2026 is difficult to convey without walking through the actual incidents. Here’s the condensed version.

Fortinet — the persistent target

Fortinet’s SSL VPN has been a continuous target since CVE-2018-13379 leaked plaintext credentials for approximately 50,000 devices. That vulnerability is still in the CISA KEV catalog. What followed was a chain: CVE-2022-42475 (heap buffer overflow, remote code execution via SSL VPN daemon), CVE-2023-27997 (“XORtigate” — pre-authentication heap overflow, CVSS 9.8), and CVE-2024-21762 (out-of-bounds write in SSL VPN, added to CISA KEV within days of disclosure).

The April 2025 Fortinet advisory described the downstream consequence of this chain: attackers had created a symbolic link between the SSL VPN user filesystem and the device’s root filesystem, maintaining read-only access to device configurations — including credentials — even after the vulnerabilities were patched. Organizations that patched promptly could still be affected if the device had been compromised before the vulnerability was remediated. As of July 2026, CISA’s KEV catalog contains 26 confirmed Fortinet vulnerabilities exploited in the wild.

In early 2026, Amazon Threat Intelligence documented a separate campaign: a financially motivated threat actor using commercial AI tools compromised over 600 FortiGate devices across 55 countries. The initial access relied on credential attacks against exposed management interfaces rather than a new zero-day vulnerability.

Ivanti — the nation-state target

Ivanti Connect Secure (formerly Pulse Secure) became a focal point for nation-state actors beginning in December 2023. China-nexus group UNC5221 exploited CVE-2023-46805 (authentication bypass) and CVE-2024-21887 (command injection) in a wave of intrusions that, by January 2024, had compromised over 2,100 devices identified by Volexity’s external scanning — with the actual number likely higher.

CISA issued Emergency Directive ED 24-01 requiring federal civilian agencies to take immediate action. Mandiant documented follow-on intrusions deploying custom malware families including ZIPLINE, LIGHTWIRE, and WARPWIRE — a credential harvester specifically designed to extract VPN credentials from device memory.

The pattern continued with CVE-2025-0282 (CVSS 9.0, unauthenticated RCE, zero-day exploitation confirmed mid-December 2024) and CVE-2025-22457 (another buffer overflow, mid-March 2025 exploitation, SPAWN ecosystem malware deployed). During these campaigns, UNC5221 also modified Ivanti’s Integrity Checker Tool (ICT) to evade detection, causing compromised devices to appear clean during automated integrity checks.

Cisco ASA — the credential spray campaign

Cisco’s pattern differs slightly. While Cisco ASA has had serious vulnerabilities (the ArcaneDoor campaign, including CVE-2024-20359 and CVE-2024-20353, demonstrated that sophisticated actors could establish persistent access to Cisco ASA devices), the most documented and widespread attack pattern against Cisco ASA VPN endpoints has been credential-based.

Rapid7 and Cisco PSIRT tracked ransomware groups Akira and LockBit running sustained brute-force campaigns against internet-exposed Cisco ASA VPN endpoints throughout 2025. GreyNoise observed over 25,000 unique IP addresses scanning ASA login portals during a single spike in August 2025. No confirmed bypass of correctly configured MFA deployments was reported during these campaigns — highlighting both the effectiveness of MFA and its absence in the environments that were successfully compromised.

Why IP Allowlisting and Firewall Rules Are Not Enough

The standard operational response to VPN attacks is perimeter restriction: limit which IPs can reach the VPN endpoint, put it behind a jump server, tighten firewall rules. These are reasonable controls. They are not sufficient.

IP allowlisting assumes a stable, manageable set of source addresses. In practice, remote workers connect from home networks, hotels, coffee shops, and client offices — none of which have predictable addresses. Every allowlist exception expands the attack surface. Most organizations quietly abandon strict allowlisting because it generates too much operational friction, or they maintain allowlists in practice but grant so many exceptions that the effective coverage is minimal.

Firewall rules reduce the exposure of the VPN endpoint to the public internet — but VPN endpoints exist specifically to accept connections from the public internet. There is no firewall rule that restricts VPN access to legitimate users while allowing remote access to work. That’s the VPN’s entire job.

Patch management addresses vulnerability exploitation but not credential theft. The FortiGate compromises that persisted after patches were applied, the Ivanti credential extraction tool deployed by UNC5221, and the Cisco ASA credential spray campaigns all operated against patched devices. A correctly patched VPN endpoint still accepts valid credentials without a second factor.

None of these controls — individually or combined — addresses the authentication gap that allows a stolen password to open a VPN tunnel.

What the Data Actually Shows: DBIR, Mandiant, CISA KEV

Three data sources converge on the same conclusion.

Verizon’s 2025 Data Breach Investigations Report found that exploitation of edge and VPN devices grew approximately eightfold year-over-year, appearing in 22% of all exploit-based breaches. Credential abuse remained the #1 overall initial access vector, present in 22% of confirmed breaches across all categories. Coalition’s 2025 Cyber Claims Report found that VPN compromise was the established entry vector in 73% of network intrusions with a confirmed initial access path.

CISA’s KEV catalog tells the vendor-specific story. Fortinet: 26 confirmed exploited CVEs as of July 2026. Ivanti: repeated zero-day exploitation across three major vulnerability waves in 2023–2025, each involving authentication bypass or pre-authentication RCE. Cisco: multiple advisories on credential-based campaigns targeting ASA endpoints specifically.

In approximately 85% of the intrusions Mandiant investigated in 2025, RDP was the lateral movement tool of choice after initial access. Across many of the VPN-focused campaigns discussed above, attackers first gained access through internet-facing VPN infrastructure before moving laterally via RDP and other protocols.

Microsoft’s Digital Defense Report 2025 provides the single most useful summary statistic: MFA blocks more than 99.2% of automated credential-based attacks. That number reflects what actually stops the attack pattern documented across Fortinet, Ivanti, and Cisco VPN incidents.

How MFA Closes the Credential Gap

MFA doesn’t patch CVEs. It doesn’t replace firmware updates or network segmentation. What it does is make stolen credentials non-functional as the sole authentication factor.

A password obtained from a phishing campaign, extracted from a leaked FortiGate configuration file, or found in a breach database cannot open a VPN session if the gateway requires a second factor that the attacker doesn’t control. The TOTP code changes every 30 seconds and is generated by a bound authenticator — an app or hardware token — that is specific to the enrolled user. The NTLM hash extracted from memory doesn’t include the current OTP. The credential list purchased on a criminal forum doesn’t include the user’s registered device.

At the network layer, MFA integrates with VPN gateways through RADIUS. The VPN gateway forwards authentication requests to a RADIUS proxy, which validates the password against Active Directory or another configured identity source and then issues a second-factor challenge. The user enters a TOTP code. Only after both factors are validated does the gateway receive an Access-Accept and open the tunnel.

This architecture works with any RFC 2865-compliant RADIUS client — Fortinet FortiGate, Cisco ASA and FTD, Ivanti Connect Secure (which supports RADIUS authentication for SSL VPN), Palo Alto GlobalProtect, SonicWall, and others. The gateway doesn’t need to know that MFA is happening in the proxy layer.

The Rapid7 and Cisco PSIRT documentation of the Akira/LockBit campaigns against Cisco ASA is worth repeating here: zero confirmed bypasses of correctly configured MFA deployments, during a sustained campaign targeting internet-exposed Cisco ASA VPN endpoints. The attackers successfully compromised password-only endpoints, while no confirmed bypasses of correctly configured MFA deployments were reported.

Practical Considerations: What to Evaluate Before Deployment

Not all VPN MFA implementations are equivalent. A few things worth confirming before selecting an approach:

On-premises vs cloud dependency. Organizations with strict security, compliance, or availability requirements may prefer an MFA server that handles the entire authentication flow locally — password validation against Active Directory or another identity source, and OTP enforcement — without relying on external cloud services.

Access-Challenge support. RADIUS Access-Challenge allows the VPN client to present a dedicated OTP input field after the password is accepted. Most modern VPN clients support this. For legacy configurations, Inline Mode (password and OTP in a single field with a separator) provides a fallback.

Hardware token support. For users without smartphones, in air-gapped environments, or in roles where mobile device use is restricted, OATH TOTP hardware tokens provide the same second-factor enforcement without any software component on the user side.

High availability. MFA infrastructure can become a single point of failure for VPN authentication. Where uninterrupted authentication is required, deploy redundant RADIUS servers or use a clustered Protectimus On-Premise Platform.

A practical RADIUS MFA for VPN deployment covers all major VPN platforms from a single server. For MFA for FortiGate specifically — including the FortiToken licensing model comparison and step-by-step RADIUS configuration — the dedicated page covers the FortiGate-specific implementation. For Cisco ASA and AnyConnect, see MFA for Cisco AnyConnect.

Conclusion: The Control That Actually Works

The VPN incident timeline of 2022–2026 contains a consistent finding: credential-based attacks work, even against patched devices, in environments that don’t enforce MFA. The inverse is also consistent: documented campaigns reported no confirmed bypasses of correctly configured MFA deployments.

Patch management closes vulnerability windows. Network segmentation limits blast radius. Monitoring catches post-breach activity. MFA is the control that makes the credential theft that follows vulnerability exploitation operationally useless as an initial access method.

The data from DBIR, Coalition, Mandiant, and CISA points in the same direction. So does the absence of documented MFA bypasses in the Akira/LockBit campaigns. If there’s one control that should be on every VPN endpoint before the next Fortinet CVE, the next Ivanti zero-day, or the next credential spray campaign, it’s a second authentication factor.