The Dutch NCSC has warned that exploitation is expected soon for two critical Check Point VPN vulnerabilities: CVE-2026-85102 and CVE-2026-85103. Check Point published fixes on September 9, 2026, and both issues carry CVSS 9.8 severity because they can be reached remotely and may allow code execution on exposed VPN infrastructure.
For small and mid-sized organizations, government contractors, and managed-service environments, this is not just another firewall patch. VPN gateways sit at the edge of the network, usually exposed to the internet by design, and they often hold the trust relationship between remote users, site-to-site tunnels, internal management networks, and privileged administrative paths. When that layer becomes remotely exploitable, the risk profile shifts from “patch during the next maintenance cycle” to “verify exposure and patch now.”
What was reported
The first issue, CVE-2026-85102, involves improper validation of certificate data during VPN negotiation. Check Point says the flaw can allow an unauthenticated remote attacker to execute arbitrary code on a Security Gateway when Remote Access VPN or Site-to-Site VPN is in use.
The second issue, CVE-2026-85103, is a heap overflow in the VPN certificate ASN.1 decoding flow. Check Point says this can allow remote code execution on Security Gateways and Security Management Servers. Affected releases include R81.20, R82, R82.10, R81.10.x, R82.00.x, and older end-of-support branches. Check Point lists R82.20 as not affected.
The Dutch NCSC assessed both likelihood and impact as high and warned that exploitation attempts are expected soon. Public proof-of-concept code had not been reported at the time of the warning, but that should not be treated as comfort. Edge-device vulnerabilities routinely move from advisory to scanning, exploit development, initial access, and post-exploitation faster than many organizations can schedule standard patch windows.
Why this matters
Remote-access and site-to-site VPN appliances are attractive targets because they combine internet exposure with privileged network position. A compromised gateway can become an initial-access beachhead, a traffic observation point, a credential-theft opportunity, or a route into management systems that were never meant to be reachable from the outside.
The certificate-processing angle also matters. Defenders often focus heavily on username/password abuse, MFA fatigue, and credential stuffing against VPN portals. Those controls are still important, but they do not stop a pre-authentication parser flaw in the VPN negotiation path. If the vulnerable service is reachable, the attacker may not need a valid account to begin the intrusion.
That distinction is important for compliance-driven teams too. A government contractor may have MFA, endpoint checks, and acceptable-use policies in place and still be exposed if the VPN edge software is behind on hotfixes or if site-to-site rules are too broad. Control maturity has to include the boring operational layer: version inventory, hotfix validation, exposure reduction, and post-patch compromise review.
Defensive takeaways
- Patch or LivePatch immediately. Check Point says the issues are addressed by LivePatch Take 24 for supported R81.20, R82, and R82.10 deployments, and by specific Jumbo Hotfix Accumulator takes and Spark firewall builds.
- Validate the fix, do not assume it landed. Check the installed hotfix or LivePatch state on each gateway, cluster member, and relevant management system. Automatic patching is useful, but verification is the control.
- Reduce site-to-site exposure. For Site-to-Site VPN, Check Point recommends disabling implied VPN rules and manually allowing UDP/500 and UDP/4500 only from specific trusted peer IP addresses where applicable.
- Prioritize internet-facing gateways first. Externally reachable VPN endpoints, MSP-managed customer gateways, and devices supporting multiple partner tunnels should move to the top of the queue.
- Review for compromise after patching. Look for unexpected configuration changes, newly created admin users, strange VPN peer activity, unusual management logins, suspicious outbound connections, and abnormal process behavior on gateway infrastructure.
- Retire unsupported branches. End-of-support firewall software turns urgent patching into emergency exception handling. If an edge security product is still on an unsupported branch, that is now a business risk, not just an IT hygiene issue.
Bulwark Black assessment
This is the kind of advisory that should trigger an incident-response mindset, not just a vulnerability-management ticket. The combination of critical severity, unauthenticated remote reachability, internet-facing placement, and government warning language makes these Check Point VPN flaws high-priority for any organization that depends on remote access or site-to-site connectivity.
For SMBs and government contractors, the practical path is straightforward: identify Check Point gateways, confirm whether VPN functions are enabled, apply the vendor fix, restrict peer access where possible, then review logs and configurations for signs that the gateway was touched before the fix landed. If patching must be delayed, exposure reduction and compensating monitoring need to happen immediately, not after the next change board.
Sources: Dutch NCSC alert; Check Point advisory for CVE-2026-85102; Check Point advisory for CVE-2026-85103.

