VPN vulnerabilities: why patching is always late

Most organisations handle VPN vulnerabilities the same way: the vendor publishes an advisory, IT assesses the impact, a maintenance window gets scheduled for an off-peak hour, the appliance is taken down, updated and rebooted, and the ticket closes. Nothing about that process is wrong. It rests on one assumption — that the clock belongs to us — and on remote-access appliances that assumption does not hold.

The more useful question is not whether you patch fast enough. It is why this class of device produces a fresh batch every year. This article answers that from the CISA Known Exploited Vulnerabilities catalogue (KEV), using the 21 August 2026 release: 1,674 entries in total.

By the end you should be able to answer three things: how large this problem actually is, why the patching clock structurally starts late, and what is still outstanding after the update is installed.

How many VPN vulnerabilities are in the KEV catalogue

KEV does not list theoretical risk. Every entry has evidence of exploitation in the wild, and under BOD 22-01 US federal agencies must remediate each one by a stated deadline. It is best read as a list of things already being attacked.

Of the 1,674 entries, 93 are remote-access or edge gateway appliances — SSL VPN portals, remote-access gateways, and perimeter firewalls carrying VPN functions. Those 93 come from nine vendors:

The Ivanti row includes entries filed under Pulse Secure before the acquisition. The same catalogue holds entries from 278 vendors. So 5.6% of the entries come from 3.2% of the vendors.

The ransomware column is more striking. KEV flags whether an entry has been used in known ransomware campaigns: across the whole catalogue, 352 of 1,674 are flagged (21%). Among these 93, 50 are flagged (54%) — the same data and the same criterion, at roughly 2.5 times the rate.

One honest caveat: those 93 are classified by vendor and product name, and where you draw the boundary moves the count by a few — counting VPN-capable firewalls or not changes the total. A handful either way does not change the order of magnitude of either ratio.

Why it is always this kind of box

VPN vulnerabilities concentrate here for reasons that have little to do with any one vendor’s engineering. There are three, and all three are properties of the position rather than the product.

It has to answer the whole internet. For staff to connect from outside, the appliance must accept unauthenticated requests from the public network — in MITRE ATT&CK terms, an external remote service (T1133). You cannot hide it behind a firewall rule, because it is the way through the firewall.

Its attack surface sits before authentication. To decide who you are, the appliance first has to parse what you sent: the TLS handshake, HTTP headers, the login form, portal parameters. All of that code runs before identity is established, so any defect in it is an opportunity for exploitation of a public-facing application (T1190). Seventeen of the 93 entries are named for authentication bypass, improper authentication or missing authorisation — and what those share is that the attacker needs no account at all, so MFA never enters the picture.

It is the trust anchor. The appliance holds every remote user’s session, the configuration, and sometimes recoverable credentials. Taking it is not gaining a foothold; it is collecting the whole roster at once.

Together those three mean switching vendors does not change the structure. It changes which advisories you follow. It does not change the fact that you operate one box that must answer the entire internet and knows who everybody is.

Why patching starts late by design

Because the two clocks do not start together.

The attacker’s clock starts when the flaw becomes usable — frequently before any advisory exists, which is the definition of a zero-day. Your clock starts when the advisory reaches you, and is followed by version checks, a scheduled window, downtime and a reboot.

The remediation deadlines in KEV show how the regulator reads that gap. The catalogue’s normal allowance is 21 days, but 23 of these 93 entries were given seven days or fewer:

The first row is not a typo. The deadline was the day after the entry appeared.

And the reason seven days is hard is rarely negligence or headcount. Taking that appliance down disconnects everyone working remotely at the same time. Whether you can patch depends on whether you can stop the box — and the VPN gateway is precisely the box you can least afford to stop. NIST SP 800-40 Rev. 4 covers the prioritisation trade-offs well, but it cannot resolve that contradiction, because the contradiction is architectural rather than procedural.

Patched and still breached: the lesson of CitrixBleed

That installing the update does not close the incident has an official source.

CVE-2023-4966, widely known as CitrixBleed, is an out-of-bounds read: an attacker can read appliance memory, and that memory contains valid users’ session tokens. With a token in hand the attacker resumes an already-authenticated session — no username, no password, no one-time code — which ATT&CK catalogues as stealing a web session cookie (T1539).

CISA and partner agencies documented in AA23-325A how LockBit 3.0 affiliates used it to bypass passwords and MFA and hijack user sessions. The required action recorded in KEV for that entry is not “apply the update”. It is apply the update and kill all active and persistent sessions.

So the default assumption in incident handling should be inverted for this class of device: “patched” means the window is closed, not that nothing left through it. Session revocation, credential rotation and a hunt for indicators belong in the patching runbook itself, on the same ticket as the update, rather than being remembered after something surfaces. What an attacker does once they hold valid credentials is broken down in how ransomware gets in.

Why one appliance falling equals the whole internal network

Because that is what the gateway model was designed to do: once you authenticate, the appliance hands you an internal address, and from then on what you can reach is decided by the network segment rather than by your identity.

This explains an official action that otherwise looks like an overreaction. In January 2024, in response to vulnerabilities in Ivanti Connect Secure and Policy Secure, CISA issued Emergency Directive 24-01, requiring federal agencies to disconnect all instances of those products from their networks by the evening of 2 February and to complete a prescribed procedure before bringing any of them back.

The regulator’s judgement was to unplug first and patch second. That judgement makes sense in exactly one situation: when what the appliance leads to is too much to risk for the sake of keeping it available.

Which is to say that treating VPN vulnerabilities as an entry-point problem understates them. They are three things stacked together — a doorway that must be public, a trust anchor holding everybody’s identity, and a path into the whole internal network. How the three architectures differ on that last point is set out in VPN, gateway ZTNA and SDP compared; the mechanism that keeps a service from answering unauthenticated requests at all is in what a software-defined perimeter is.

Five things to do that are not patching

Keep patching. These five sit alongside it, and none of them requires a purchase:

1. Take management interfaces off the public internet. Several KEV entries target an appliance’s management plane rather than its VPN service. There is no reason for that plane to answer the whole internet.
2. Check your own device and firmware list against KEV instead of waiting for a vendor newsletter. In Taiwan, TWCERT/CC is worth reading alongside it.
3. Write “revoke all sessions, rotate credentials and keys” into the patching runbook, on the same ticket as the update rather than as a later remedy.
4. Inventory whatever else answers the whole internet the way the VPN does. It is rarely just one box; the method is in what your company exposes on the public internet.
5. Ask one question: after authenticating, how many hosts can a user actually reach? If the answer is “the whole segment”, then every hour spent so far has gone into shortening the exposure window while nothing has been done about the loss inside it.

If the answer to the fifth is unsatisfying, the thing to fix is the architecture rather than the patching speed — choosing and migrating off a VPN covers how that path is sequenced and how to run the parallel period.

Terms and further reading

Every figure above can be recomputed: KEV publishes a JSON version of the catalogue, and filtering the vendor and product fields against your own device list gives you the entries that apply to you. If you would like the exposure window assessed against a specific environment, get in touch.