January 2025. Ivanti drops an emergency advisory for CVE-2025-0282 — a pre-authentication remote code execution vulnerability in their Connect Secure VPN gateway, CVSS score 9.0 (on a scale of 0–10, where 10 is most critical). “Pre-authentication remote code execution” means an attacker can run malicious code on the device without needing a username or password — just a network connection. Exploitation is already happening in the wild. Nation-state actors are inside customer networks before most administrators have even read the email.

Sound familiar? It should. The exact same story played out in January 2024, and in 2023, and in 2021, and in 2020. Different CVE numbers, same victims, same attackers, same post-exploitation playbook.

This isn’t bad luck. It’s structural.

TL;DR

  • Enterprise VPN and gateway products keep getting owned because of five compounding structural problems, not random chance
  • The products sit at the worst possible position: internet-facing, pre-authentication reachable, and deeply trusted on the inside
  • Acquisitions like Pulse Secure → Ivanti carry legacy codebases that were never properly audited
  • Enterprise patching cycles mean vulnerabilities stay open for weeks or months after patches ship
  • Defenders can’t just patch faster — they need architectural changes

The Five Reasons This Keeps Happening

1. Internet-Exposed by Design

A VPN gateway or SSL inspection appliance has one job: sit on the internet and accept connections from anyone. That’s the product. It can’t hide behind another firewall. It can’t be network-segmented away from untrusted traffic. By design, every unauthenticated attacker on the planet can send packets directly to it.

This is fundamentally different from an internal application server that might get compromised after an attacker is already in the network. VPN gateways are the first thing attackers touch. Every authentication bypass, every pre-auth memory corruption bug, every path traversal (a technique where an attacker navigates to files outside the intended directory by manipulating file paths) — all of it is reachable without any prior foothold.

Compare this to, say, a vulnerable internal HR portal. An attacker needs to be inside the network first. With a gateway device, the attacker connects from their keyboard in another country and executes code on your network perimeter.

2. The Position Is Too Valuable to Ignore

Network edge devices aren’t just an entry point — they’re a perfect entry point. Consider what a compromised VPN gateway gives an attacker:

  • Network position: Traffic from the gateway is trusted by internal firewalls and segmentation rules
  • Persistence: Security appliances are rarely reimaged. A web shell (a malicious script planted on a web server that gives attackers persistent remote control) or implant installed on a gateway can survive for months or years
  • Credential harvesting: VPN gateways process authentication credentials for every user. Compromise the gateway, harvest credentials passively
  • Lateral movement foundation: The device has routes to everything — corporate networks, cloud environments, OT/ICS networks (Operational Technology and Industrial Control Systems — factory floors, power grids, critical infrastructure)

This is why nation-state groups specifically hunt these devices. China-nexus actor UNC5221 has been repeatedly attributed to Ivanti gateway exploitation, most recently deploying the SPAWN malware ecosystem via CVE-2025-22457. The SPAWN toolkit is designed specifically to survive factory resets on Ivanti devices — attackers understand the target better than most defenders do.

When the prize is this good, attackers invest serious resources into finding vulnerabilities. Which means they will find them.

3. Legacy Code That Nobody Has Fully Audited

Here’s the Ivanti origin story that explains a lot.

Ivanti is a security company assembled almost entirely through acquisitions. Their flagship VPN product, Ivanti Connect Secure, was originally Pulse Connect Secure, which was originally built by Pulse Secure, which itself grew from technology spun out of Juniper Networks’ SA Series SSL VPN product line — code that dates back to the early 2000s.

Ivanti acquired Pulse Secure in 2020. Before that, Pulse Secure was already carrying over a decade of accumulated technical debt. When a company acquires another, the acquiring engineers get access to the source code, but they don’t get the years of institutional knowledge about why certain design decisions were made, which code paths are dangerous, or which components have never been properly reviewed.

The CVEs reflect this directly. CVE-2026-1281 and CVE-2026-1340, two critical zero-days discovered in early 2026 affecting Ivanti EPMM, both trace back to bash scripts used by the Apache web server to handle URL rewriting. Unsafe bash scripting patterns, in a product that handles authentication for enterprise mobile device management. This is what legacy code debt looks like in practice.

Fortinet has similar archaeology. Their FortiOS codebase is old. Palo Alto’s PAN-OS has components that predate the company’s current security practices. The common thread is not malice — it’s the reality that security software is built by humans, maintained across decades, and subjected to acquisition and rebranding cycles that disrupt continuity.

4. Enterprise Patching Cycles Are Slow by Design

Security researchers and vendors publish CVE advisories assuming organizations will patch within days. Enterprise reality is different.

A typical large organization faces the following when a critical VPN gateway patch ships:

  1. Change management process: The patch must be tested in staging, approved by a change control board, and scheduled for a maintenance window — often weekly or biweekly
  2. Uptime requirements: VPN gateways serve thousands of remote users. A maintenance window at 2 AM on a Sunday might be the earliest acceptable time
  3. Testing burden: Vendors have shipped broken patches before. Admins have been burned. They test first
  4. Staffing: The team responsible for patching may not have spare capacity this week

Germany’s BSI (Federal Office for Information Security) tracked the 2026 Ivanti EPMM exploitation and found evidence of active attacks traced back to July 2025 — six months of exploitation before most organizations had fully patched the previous vulnerabilities, let alone prepared for new ones.

This isn’t negligence. It’s the structural mismatch between how fast attackers move and how fast enterprises can safely move.

5. Monoculture Means One Bug, Thousands of Victims

When Ivanti Connect Secure has a pre-auth RCE vulnerability, the exploitation isn’t targeted at one organization. Attackers scan the entire internet for exposed Ivanti instances — tools like Shodan, Censys, and FOFA (internet-wide scanning services that continuously index every publicly accessible device and service) make this trivial — and then exploit every reachable instance automatically.

Ivanti Connect Secure is used by over 40,000 organizations worldwide. A single working exploit can compromise thousands of networks in hours. This makes the investment in finding the vulnerability extraordinarily worthwhile for attackers: one CVE, thousands of victims.

Compare this to a bespoke internal application with ten users. A vulnerability there might affect one organization. A vulnerability in an enterprise security appliance deployed globally affects everyone simultaneously.

The CVE Timeline That Should Concern You

This isn’t a recent problem. Here’s a condensed timeline of critical Ivanti/Pulse Secure exploitations:

YearCVEImpactAttribution
2020CVE-2019-11510Pre-auth file read, credential theftMultiple threat actors
2021CVE-2021-22893Pre-auth RCE on Pulse Connect SecureUNC2630 (China-nexus)
2023CVE-2023-35078Pre-auth API access, EPMMActively exploited
2023CVE-2023-46805Auth bypass, Connect SecureUNC5221
2024CVE-2024-21887Command injection, Connect SecureUNC5221
2025CVE-2025-0282Pre-auth RCE, Connect SecureUNC5221, SPAWN malware
2025CVE-2025-22457RCE, Connect SecureUNC5221
2026CVE-2026-1281Pre-auth RCE, EPMMWidespread automated exploitation

The pattern is not subtle. Same product family, same threat actor cluster, year after year. At some point this stops being a vulnerability management problem and starts being an architectural problem.

Why “Just Patch Faster” Isn’t the Answer

Patching faster is necessary but not sufficient. Consider:

The zero-day window: CVE-2025-0282 was exploited before the patch existed. CVE-2025-22457 was being actively exploited at the time of disclosure. You cannot patch a vulnerability that has no patch yet.

The exploit gap: Mandiant estimated that the median time from vulnerability disclosure to active exploitation has dropped to under 5 days for high-profile vulnerabilities. Many organizations cannot patch in under 5 days.

Detection is broken: Traditional security monitoring often treats VPN gateway traffic as trusted. Web shells installed on a gateway device may generate no alerts at all in a standard SIEM (Security Information and Event Management — a platform that aggregates and analyzes logs from across the network) deployment because the gateway is a “trusted” network asset.

What You Can Actually Do

Immediate Actions

1. Inventory your exposed edge devices

Pull a list of every internet-facing device in your environment: VPN gateways, SSL inspection proxies, WAFs, remote access solutions. This list should include firmware versions. If you don’t know what version something is running, that’s the first problem.

Terminal window
# Quick Shodan check for your own ASN
shodan search "org:'Your Organization' product:ivanti"

2. Subscribe to vendor security advisories directly

Don’t rely on news articles. Subscribe to Ivanti, Fortinet, and Palo Alto security bulletins via email or RSS. When a critical advisory drops, you want to know within hours, not days.

3. Monitor CISA KEV (Known Exploited Vulnerabilities)

The CISA KEV catalog lists vulnerabilities with confirmed active exploitation. If a CVE affecting your infrastructure appears there, treat it as an emergency:

import requests


kev = requests.get("https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json").json()
ivanti_vulns = [v for v in kev['vulnerabilities'] if 'ivanti' in v['vendorProject'].lower()]
for v in ivanti_vulns[-5:]:  # Show 5 most recent
    print(f"{v['cveID']} — {v['vulnerabilityName']} (added {v['dateAdded']})")

Architectural Changes

4. Implement network segmentation at the gateway

The gateway’s internal-facing side should not have unrestricted access to your flat corporate network. Place the VPN termination point in a DMZ (Demilitarized Zone — a network segment that sits between the public internet and your internal network, isolated from both). Force VPN traffic through a firewall before it reaches internal resources. This doesn’t prevent gateway compromise, but it limits what an attacker can reach after compromise.

5. Enable integrity verification and logging

Modern gateway products offer built-in integrity checking. Ivanti’s Integrity Checker Tool (ICT) detects modifications to system files that might indicate web shell deployment. Run it regularly — not just after incidents.

Log everything the gateway produces and ship those logs to an external SIEM immediately. If attackers compromise the gateway, the first thing they’ll do is clear local logs.

6. Consider Zero Trust architecture as a long-term replacement

Traditional VPN gateways create a binary: outside the network vs. inside the network. Zero Trust Network Access (ZTNA) solutions eliminate the “inside” concept entirely — every connection is authenticated and authorized regardless of network position. This doesn’t eliminate vulnerabilities in the ZTNA appliance itself, but it significantly reduces the blast radius of a compromise.

This is a multi-year project, not a weekend fix. But the direction of travel is clear.

7. Have an incident response plan for gateway compromise

Ask yourself: if your VPN gateway is compromised today, what do you do in the first hour? If you don’t have a written answer, write one. It should include:

  • How to take the gateway offline without disrupting all remote workers permanently
  • How to determine the scope of compromise (what was the gateway connected to?)
  • How to hunt for web shells and persistence mechanisms
  • Who to call (IR retainer, vendor support, legal)

The Uncomfortable Truth

The enterprise security appliance market is a structural vulnerability factory, and the economics aren’t changing. Vendors compete on features, not on code quality. Enterprises buy based on analyst reports and integration with existing tooling, not on security audit results. Acquisitions roll up legacy codebases without the budget for full security reviews. Customers accept the risk because alternatives don’t exist or aren’t mature.

Until the market starts punishing vendors for repeated critical CVEs — through regulatory requirements, contractual penalties, or customer churn — the incentives won’t change. Ivanti has now had critical pre-auth RCE vulnerabilities in the same product family for six consecutive years. The product is still widely deployed.

The attackers know this. They’re budgeting for it. Your security program should too.

What You Can Do Today

  1. List every internet-exposed edge device and its current firmware version
  2. Subscribe to vendor security advisories for every product on that list
  3. Add CISA KEV to your weekly review process
  4. Verify your gateway logs are being shipped to an external SIEM
  5. Run the vendor’s integrity checking tool on your current gateway deployments
  6. Draft a one-page gateway compromise response plan

None of these require budget approval. All of them reduce your risk today.

Sources