Cybersecurity 6 min read

The Dutch Warned About Check Point's VPN Flaws Before Anyone Exploited Them

Two pre-authentication flaws in Check Point VPN were patched on 9 September. Three days later the Dutch NCSC said attempts are coming. That order is the unusual part.

Kenji Tanaka
Developer Tools & Cloud Analyst
Published 14 Sep 2026, 7:07 AM (SGT)
Share:
A row of coloured network cable connectors standing upright on a white background — illustrating the gateway hardware these VPN flaws sit in. A row of coloured network cable connectors standing upright on a white background — illustrating the gateway hardware these VPN flaws sit in. Photo by blickpixel on Pixabay
Advertisement

14 SEP 2026 — The Dutch national cyber security centre has warned that two critical flaws in Check Point VPN products are about to be exploited. Not that they have been. That they are going to be.

The order is the story. Edge-appliance advisories usually arrive after the fact: attackers were inside for weeks, the vendor shipped a fix, and the warning landed while the damage was already being counted. Here the patch came on 9 September and the warning on 12 September, with no public exploit code and no observed exploitation as of the warning.

The two flaws

CVE-2026-85102 is an improper validation of certificate data during VPN negotiation. A remote attacker can use it to execute arbitrary code on a Security Gateway.

CVE-2026-85103 is a heap overflow in the decoder that parses VPN certificates, and its reach is wider: Security Gateways and Security Management Servers both. Compromising a management server is materially worse than compromising one gateway, because the management server is what configures the others.

Both are reported as pre-authentication. Neither needs credentials, a session, or any prior foothold. The attack surface is the VPN negotiation itself, which is the one service on the box that has to accept connections from anywhere in order to do its job.

A note on the severity numbers

Both flaws are being reported at CVSS 9.8, and the figure is plausible on the described vector: network reachable, no authentication, no user interaction, code execution.

We are flagging it as reported rather than established, because the scoring authority is not named in the coverage we can see and Check Point's own advisories sit behind a support login. The number travels further than its source. A 9.8 from a vendor, from a national agency, or from a researcher writing a blog post are three different claims, and the difference disappears the moment the figure lands in a ticket. If you want to see how the vector decomposes into the score, our own CVSS calculator will show you which metrics are doing the work.

9 SepCheck Point shipped the fixes
12 SepThe Dutch NCSC issued its warning
0Public exploits at the time of the warning
R82.20The only listed version not affected

What is affected, including what is not supported

The affected list covers R81.20, R82, R82.10, R81.10.x and R82.00.x, plus the end-of-support releases R80 through R80.40, R81 and R81.10. R82.20 is not affected.

The end-of-support entries are the ones to read twice. An organisation running R80.40 in 2026 is not going to apply a fix, because there is no supported fix to apply and there is usually a reason the box was never upgraded — a dependency, a change freeze, or nobody left who remembers what it terminates. Those are the devices that will still be reachable in six months.

Check Point has published advisories sk1000117 and sk1000118, shipped the fixes through its jumbo hotfix accumulators, and made temporary protection available through its live-patch mechanism. For site-to-site VPN specifically, restricting UDP/500 and UDP/4500 to known peer addresses removes the exposure from the open internet, which is a reasonable stopgap for gateways that only ever talk to a fixed set of partners. It does nothing for remote-access VPN, where the whole point is that the client could be anywhere.

Why the warning came early

The Dutch agency assessed both the likelihood of exploitation and the potential impact as high, and said it expects attempts soon. That assessment does not require intelligence about a specific actor. It follows from the shape of the target.

Advertisement

A pre-authentication flaw in a VPN gateway is one of the most valuable classes of bug there is. The device sits at the edge by definition, it is findable by scanning, it terminates the tunnel that everything else trusts, and it is frequently excluded from the endpoint tooling that watches the rest of the estate. Once a patch exists, the patch itself is the specification: diffing it tells a competent researcher where the bug is, and the window between fix and working exploit for this class of appliance has repeatedly been measured in days.

So the warning is less a prediction than an inference, and the honest way to read it is as a clock starting rather than an alarm going off.

What this changes for anyone running one

The patch is available. There is no analysis to do, no indicator to hunt for, and no argument to have about whether the risk is theoretical. The obligation is to apply the fix.

The harder question is inventory. Organisations routinely discover a gateway nobody owns: a spare at a branch office, a management server left running after a migration, a failover pair that was never patched because failing over is frightening. Those are found by looking, not by waiting for an alert.

If a box cannot be patched this week, the site-to-site restriction above is the mitigation worth applying, and it should be applied with the assumption that it is temporary rather than sufficient.

What to watch

The Dutch assessment is testable. If nothing is observed in a month, that tells you something about how fast this class of bug actually gets weaponised.

A listing in the United States known-exploited catalogue is the second marker. That entry carries a federal remediation deadline, and it tends to be the moment an advisory turns into an internal priority for organisations that had filed it under later.

The third is whether the early-warning pattern holds at all. A national agency getting ahead of exploitation rather than chasing it is the outcome every disclosure process claims to want, and it happens rarely enough to be worth noticing.

Advertisement
Kenji Tanaka
Developer Tools & Cloud Analyst

Kenji Tanaka covers developer tools, cloud platforms, DevOps, CI/CD, and software supply-chain topics for RECATOOLS.

View author profile → · Editorial policy

About this byline Kenji Tanaka is a RECATOOLS editorial persona for developer tools, cloud, DevOps, and software supply-chain coverage. Articles are produced and reviewed under RECATOOLS editorial supervision.

Corrections policy

Advertisement