SSL VPNs: 56 exploited flaws; IPsec: 8. Fortinet has already chosen

0156 to 8: where the exploited flaws sit

CISA’s catalogue lists only flaws with evidence of exploitation in the wild, which makes it a better guide to real risk than a count of published CVEs. I split the VPN-related entries by the component CISA’s own description names. Flaws in SSL VPN appliances and SSL VPN components outnumber flaws in IKE/IPsec implementations seven to one.¹

The obvious objection is exposure. If more organisations publish SSL VPN portals for remote staff than run IPsec remote access, as seems likely, attackers have more reason to study them, and a raw count rewards the popular product. That may be so, and it is also the point: the exposure is what you inherit when you choose the design. The count cannot say that a given SSL VPN is less carefully engineered than a given IPsec gateway. It does say where attackers have actually got in, repeatedly, since the catalogue opened, and a buyer choosing between the two is choosing which list to join.

02The SSL count is not a 2021 problem

A reasonable objection is that the SSL number is history: Pulse Secure’s bad year and Fortinet’s 2018 portal flaws, all loaded into the catalogue when it opened in November 2021. The dates say otherwise. 22 of the 56 SSL VPN entries were added from January 2025 onward, 13 in 2025 and 9 more by the end of September 2026, most of them NetScaler Gateway and SonicWall SMA.¹

Two refinements make the comparison fairer, and neither changes it. First, 12 of the 56 SSL entries sit in a management console or need an administrator login; take them out and 44 remain. Second, IPsec is not immune. Four of its eight entries arrived from 2025 onward, including a Check Point flaw that let an attacker “bypass user authentication and establish a remote access VPN connection” through IKEv1 (CVE-2026-50751, added 8 June 2026), and two WatchGuard flaws in the IKE daemon.¹

03Why: a web application against a key exchange

Encryption is not the difference. Both protocols use the same modern ciphers when configured properly, and the 2024 post spent most of its length on a distinction that does not decide anything. What differs is how much code an attacker can reach before logging in.

An SSL VPN is a web server with a login page, and usually much more: a clientless portal that rewrites internal web pages, single sign-on endpoints, file-share bookmarks, and on many products the management interface on the same appliance. Each is a parser exposed to anyone on the internet. An IPsec gateway exposes the IKE daemon, which negotiates keys, and then accepts only packets that are already authenticated. NSA and CISA made the same argument in their joint information sheet of 28 September 2021: “Avoid selecting non-standard VPN solutions”, a class in which they place SSL/TLS VPNs, and “NSA and CISA recommend standardized Internet Key Exchange/Internet Protocol Security (IKE/IPsec) VPNs”. They also advise administrators to “disable the SSL/TLS proprietary or non-standards-based VPN fallback, if possible”.²

The original post’s strongest case for SSL was convenience: it works from any browser, on almost any network, with nothing to install. That convenience is exactly the exposure. A portal any browser can reach is a portal any scanner can reach.

04Fortinet has already made the call

The most telling evidence is a vendor’s own roadmap. Fortinet has six SSL VPN flaws in the catalogue, all six marked as used in ransomware.¹ In April 2025 it announced that FortiOS 7.6.3 would remove SSL VPN tunnel mode entirely, from both the interface and the command line, and that existing tunnel-mode configuration would not be carried across an upgrade.⁴ Its own technical note tells customers to “migrate the SSL VPN to the IPsec VPN”.³

The same FortiClient agent carries both SSL and IPsec tunnels, so for a FortiGate estate the switch is configuration and testing, not a new licence.⁵ For estates on other firewalls, the step is the same in substance: build the IPsec remote-access profile, move a pilot group, then switch the SSL portal off rather than leave it as a fallback.

1. Inventory who uses the portal. Export a month of SSL VPN logins and split them into managed laptops, branch devices, and everyone else. The third group is the one IPsec will not serve well.
2. Build the IPsec profile with certificates and MFA. Pre-shared keys on a remote-access profile turn every laptop into a copy of the same secret.
3. Move a pilot group, then everyone on a managed device. Test the applications that broke on the SSL tunnel too: softphones, file shares, anything that relies on split tunnelling.
4. Give the remaining users zero trust access, then turn the portal off. A portal kept “just for the contractors” is still a portal on the internet.