A rare disclosure: the vendor found it first
On September 9, Check Point disclosed two vulnerabilities in how its Security Gateway, Quantum Security Management Server and Spark Firewall products validate and process VPN certificates. CVE-2026-85102 is a failure to properly validate certificate trust during VPN negotiation. CVE-2026-85103 is a heap based buffer overflow in how the same systems decode the ASN.1 structure of VPN certificates. Both carry a CVSS score of 9.8, the practical ceiling for a remote, unauthenticated vulnerability, and both live in the same certificate processing code path.
What makes this disclosure unusual is the source. Check Point states plainly that it found both flaws through internal research, not through an incident response engagement or a third party bug bounty submission, and that it has seen no evidence either has been used in an attack. That is a meaningfully different posture than most of the KEV additions and active exploitation reports that dominate the security news cycle, and it deserves to be read that way rather than folded into the same panic as a confirmed breach.
Why the same code path producing two perfect scores matters
Two independent CVSS 9.8 vulnerabilities emerging from the same certificate processing routine is not a coincidence worth shrugging off. It suggests the underlying code handling VPN certificate trust and ASN.1 decoding has structural weaknesses that a single patch cycle is unlikely to fully resolve. Security researchers who study vendor disclosure patterns treat clustered critical bugs in one subsystem as a leading indicator that more findings, from Check Point's own team or from outside researchers now aware the area is fragile, are likely to follow in coming months.
For enterprise security teams, this changes the calculus from patch and move on to patch and watch. The certificate validation and ASN.1 decoding paths in Check Point's VPN stack should go on a shortlist for heightened monitoring, not just this patch cycle's remediation checklist. Treating a cluster of related critical bugs as a one time event, rather than a signal about a code area, is how organizations end up caught flat footed by the next disclosure in the same subsystem six months later.
The patch rollout has real gaps
Check Point began automatic rollout of a live patch on September 9 for customers running R81.20, R82.00 and R82.10, alongside Jumbo Hotfix updates specific to each deployed version: Take 43 or below for R82.10, Take 125 or below for R82, and Take 165 or below for R81.20. On paper this is a fast, low-friction remediation path that does not require a maintenance window, which is exactly the kind of response security teams want to see from a vendor disclosing a perfect score bug.
In practice, customers running R81.10, an older but still commonly deployed branch, reported that no patch was available for their version at disclosure time. Check Point's advisory recommended disabling implied VPN rules as an interim mitigation, but multiple customers described that guidance as too vague to act on without more specific configuration detail. A live patch that does not cover a widely deployed legacy branch, paired with mitigation advice teams cannot confidently implement, leaves a real gap between the vendor's messaging and what security teams can actually execute this week.
A government advisory arriving the same evening
The Canadian Centre for Cyber Security issued its own advisory on the Check Point flaws the same evening as the vendor disclosure, an unusually fast turnaround for a government cybersecurity agency responding to a vulnerability with no confirmed exploitation. That speed reflects how VPN gateways have become the default first target in ransomware intrusion chains over the past several years, a pattern serious enough that agencies now move on internally discovered critical bugs almost as quickly as they move on confirmed active exploitation.
For CTOs, a same-day government advisory on an unexploited bug is itself useful signal. It means the agencies tracking real-world intrusion patterns view VPN certificate handling as enough of a proven attack surface that they are not waiting for confirmed abuse before pushing organizations toward remediation. That is a more conservative posture than CISA's KEV catalog, which by design only lists confirmed exploitation, and it is worth treating with comparable seriousness rather than lower urgency.
VPN infrastructure keeps drawing this kind of attention
This disclosure lands in the same week that CISA added actively exploited Cisco, Citrix and Fortinet edge device flaws to its own must patch catalog, a coincidence of timing that nonetheless points at a durable trend. VPN gateways and firewall management consoles sit at the exact seam between an organization's internal network and the open internet, and every major security vendor's own infrastructure is now a viable target for the same class of attacker that targets its customers.
For enterprise buyers, this is a reason to ask VPN and firewall vendors harder questions about their own internal vulnerability research programs during procurement and renewal conversations, not fewer. A vendor that finds and discloses its own critical bugs before attackers do is demonstrating exactly the kind of security investment that should factor into a vendor risk assessment, even when the headline reads like bad news. Ask specifically how many of the vendor's last ten critical disclosures were caught internally versus reported by outside researchers or discovered mid-breach, since that ratio says more about a vendor's security maturity than any marketing page ever will.
What to do this week
Security teams running any of the affected Check Point products should not assume the live patch completed automatically. Confirm patch status directly on each gateway, management server and Spark Firewall device, and prioritize any device still on R81.10 for either an accelerated upgrade path or a compensating control that goes beyond the vendor's general guidance on disabling implied VPN rules, since that advice alone has already proven insufficient for teams trying to act on it.
Longer term, this disclosure is a good prompt to formalize how your organization tracks vendor-discovered versus externally-discovered critical vulnerabilities across the perimeter stack, since the two carry different urgency signals and different confidence levels about whether attackers already have a working exploit. A patch tracking process that treats every CVSS 9.8 identically, regardless of exploitation status, will either under-react to active threats or over-react to responsibly disclosed ones, and neither serves a security team well over a full year of disclosures.
