Check Point VPN Flaw 2026: Patch Now, NCSC Warns

Two critical bugs, one unauthenticated route to full compromise

The Dutch Nationaal Cyber Security Centrum (NCSC) is warning that exploitation of CVE-2026-85102 and CVE-2026-85103 in Check Point VPN is imminent; the NCSC says no public proof-of-concept exploit has been reported. CVE-2026-85102 stems from improper validation of certificate data during VPN negotiation, letting a remote attacker execute arbitrary code on a Security Gateway. CVE-2026-85103 is a heap-based buffer overflow in the VPN certificate ASN.1 decoder, which can enable remote code execution on both Security Gateways and Security Management Servers. Both carry a CVSS score of 9.8, as reported by The Hacker News.

The flaws are described as enabling unauthenticated remote code execution, which is exactly why the NCSC has flagged the likelihood and impact of attacks as high. The agency says successful exploitation could hand an attacker full control of a system, access to confidential data, and the ability to disrupt operations.

Why the warning window matters more than the absence of a public exploit

Check Point disclosed both issues itself on 9 September 2026, alongside advisories sk1000117 and sk1000118, and said it had no indication of active exploitation at the time. That's the calm before the storm pattern the NCSC is now reacting to: a vendor-led disclosure with fixes already available typically triggers a race between defenders patching and attackers reverse-engineering the fix to build a working exploit. The NCSC's assessment that exploitation attempts will occur soon reflects that race, not evidence of attacks already under way.

For UK infrastructure teams, that timing gap is the entire opportunity. Every day between disclosure and a patched estate is a day of exposure on an internet-facing VPN gateway, which is precisely the kind of asset that sits at the top of any sound vulnerability management priority list.

Which versions are exposed and what actually fixes them

The affected branches are R81.20, R82 and R82.10, at or below the vulnerable Jumbo Hotfix Accumulator take levels set out in Check Point's advisories sk1000117 and sk1000118. Check Point also lists R80 through R80.40, R81 and R81.10 as end-of-support releases that sit outside the scope of the published fixes, per BleepingComputer's reporting. A Canadian Centre for Cyber Security advisory cited by The Hacker News broadens the picture further, listing Security Gateway, Security Management Server and Spark Firewall as affected product families — so this isn't confined to perimeter VPN boxes alone.

Check Point's fix is delivered through LivePatch Take 24 for R81.20, R82 and R82.10. Alternatively, it is delivered through Jumbo Hotfix Accumulator Take 44 or later (R82.10), Take 126 or later (R82), and Take 166 or later (R81.20). Spark customers need Spark R82.00.10 Build 2325 or later, or Spark R81.10.17 Build 4968 or later. R82.20 is not affected by either flaw.

• •LivePatch Take 24 (R81.20, R82, R82.10) — no reboot required for supported CPLP configurations; check whether your configuration is actually covered
• •Jumbo Hotfix Accumulator Take 44+/126+/166+ for R82.10/R82/R81.20 respectively
• •Spark R82.00.10 Build 2325+ or Spark R81.10.17 Build 4968+
• •End-of-support branches (R80–R80.40, R81, R81.10) are not covered by the published fixes — migration or replacement is required

The catch with automatic mitigation

Check Point says CPLP users should have received protections automatically for supported configurations since 9 September, without a server reboot, according to its community forum posts. Coverage applies to R82.10, R82 and R81.20 only, and not every configuration is supported — so teams need to actively confirm protection status rather than assume it. For organisations still running Site-to-Site VPN components, the NCSC's interim advice is to tighten VPN rules to permit only specific, trusted IP addresses while patching is completed.

What this means for UK buyers beyond this week's patch cycle

A 9.8-rated, unauthenticated remote code execution pair on a widely deployed enterprise VPN platform is the kind of event that should prompt a wider conversation, not just a patch ticket. Teams relying on network security solutions built around perimeter VPN concentrators are carrying concentration risk: one appliance family, one certificate-handling bug, and a large slice of remote access goes dark or gets compromised at once.

That's the argument increasingly being made for a phased VPN to ZTNA migration, where remote access is brokered per-application rather than through a single always-on gateway that becomes a high-value target the moment a flaw like this surfaces. Pairing that shift with a zero trust access model reduces the blast radius of the next VPN-grade CVE, whenever it lands. In the meantime, organisations that can't patch immediately should lean on managed detection & response to watch for anomalous authentication and gateway process behaviour, and treat this as a live input into ransomware protection planning, given how frequently VPN footholds precede extortion incidents.

Action checklist for this week

Confirm your Check Point branch and current hotfix take level against the vulnerable thresholds before assuming you're covered. Apply LivePatch Take 24 or the relevant Jumbo Hotfix Accumulator immediately, verify CPLP auto-mitigation actually applied to your configuration, restrict Site-to-Site VPN access to trusted IPs as an interim control, and flag any end-of-support branch (R80.x, R81, R81.10) for urgent migration since these releases are not covered by the published fixes. Anyone managing a broader estate should fold this into ongoing cyber security services review cycles rather than treating it as a one-off fire drill.