The Dutch National Cyber Security Centre has issued an urgent warning that exploitation of two recently disclosed Check Point VPN vulnerabilities, CVE-2026-85102 and CVE-2026-85103, is likely to begin soon. Both vulnerabilities carry CVSS scores of 9.8 and can potentially allow unauthenticated remote attackers to execute code on affected systems. CVE-2026-85102 affects the VPN connection establishment process and can allow an attacker without valid credentials to bypass expected security controls and execute arbitrary code, while CVE-2026-85103 affects certificate processing and can also lead to unauthenticated code execution through malformed certificate data. The NCSC assesses both the probability of exploitation and the potential impact as high and is advising organizations to install Check Point’s security updates as quickly as possible. Importantly, however, the agency says there is currently no public proof-of-concept exploit and no confirmed exploitation in the wild, so the warning should be understood as a strong prediction based on exploitability and exposure rather than confirmation that attacks are already underway. 

That distinction matters because organizations frequently wait for the wrong milestone before treating a vulnerability as urgent. Some teams patch when the vendor labels a flaw Critical, others wait for a public exploit, and others unfortunately wait until CISA adds it to KEV after attackers have already demonstrated the technique against real victims. CVE-2026-85102 and CVE-2026-85103 provide a useful example of why that sequence can be too slow for internet-facing security infrastructure. The affected components are part of VPN gateways that are deliberately reachable from untrusted networks. They process authentication and certificate data before the remote party has necessarily established a trusted session, and both flaws potentially permit code execution without prior credentials. Once technical details of the fixes are available, attackers can compare patched and vulnerable builds, reverse-engineer the relevant changes, and begin constructing exploit code. The absence of a public PoC therefore does not mean the vulnerability is operationally safe; it merely means defenders may still have a short lead over attackers.

CVE-2026-85102 is particularly concerning because it sits in the VPN negotiation path itself. VPN infrastructure is designed to establish trust between remote systems, which means parts of the protocol stack necessarily process data from unauthenticated clients. A flaw in that path can undermine the security boundary before normal authentication has had the opportunity to protect the system. This is an important architectural point: MFA, strong user passwords and strict account policies are extremely useful only after the software safely reaches the authentication decision. If attacker-controlled negotiation traffic can exploit privileged code before that stage, the strength of the user’s credentials becomes largely irrelevant. The VPN gateway has effectively been compromised while still deciding whether the remote party should be trusted.

CVE-2026-85103 presents a related but more traditional memory-safety problem in certificate processing. Certificates are often mentally associated with trust, encryption and authentication, but before any certificate can establish trust, the gateway first has to parse attacker-controlled structured data. ASN.1 and certificate formats are complex, highly nested and variable-length, which makes safe parsing critical. A malformed certificate may eventually be rejected as invalid, but if memory corruption occurs during decoding, the attacker may gain code execution before the validation process reaches that rejection. The lesson is simple but important: cryptographic trust does not make the certificate parser trustworthy. Strong algorithms and correctly issued certificates cannot compensate for unsafe memory handling in the code that processes them.

The position of the vulnerable systems substantially increases the potential impact. Check Point Security Gateways commonly sit at the enterprise edge, terminating VPN connections and enforcing network access policy between external users, branch offices and internal networks. Successful compromise therefore gives attackers control of infrastructure that may have direct connectivity into sensitive parts of the organization. The attacker is no longer trying to penetrate a firewall from outside; they may now be operating from the firewall itself. That can provide access to internal addressing, routing information, VPN relationships and trusted network paths that would otherwise require significant reconnaissance to discover.

The risk becomes even more serious where management infrastructure is affected. Security gateways and management servers represent concentrated trust because they hold configuration, policy and credentials related to multiple network segments and systems. A compromised ordinary endpoint may reveal one user’s data, while a compromised network-security platform can reveal how the enterprise is structured and which paths defenders intentionally permit. That is why firewall, VPN and management infrastructure should be treated as Tier-0 or equivalent assets and protected at least as aggressively as identity servers, hypervisors and RMM platforms.

The Dutch NCSC’s warning also deserves attention because it explicitly anticipates exploitation before public exploit code is available. The agency says it expects attempts to exploit the vulnerabilities soon and therefore recommends immediate deployment of updates. This is exactly the period in which proactive remediation provides the greatest value. Once exploitation becomes widespread, patching changes from prevention into containment, and defenders then need to determine whether vulnerable systems were already compromised before the update arrived.

That difference is operationally important. Patching before exploitation can reasonably be treated as vulnerability management. Patching after exploitation begins should increasingly be treated as vulnerability management plus incident response. Organizations may need to inspect authentication logs, VPN negotiation activity, process crashes, unexpected configuration changes, newly created accounts, unusual outbound communications and other signs of post-compromise behavior. The cost of waiting therefore increases sharply once attackers begin using the flaw in the wild.

The history of Check Point VPN exploitation provides additional reason not to wait. Earlier in 2026, CVE-2026-50751 affected Check Point Remote and Mobile Access VPN products using legacy IKEv1 configurations. The Dutch NCSC initially warned about active exploitation and later updated its advisory after public PoC code became available, noting that publication of the exploit increased the likelihood of broader abuse. That earlier incident demonstrates how quickly a VPN vulnerability can move from vendor disclosure to public weaponization. Organizations evaluating the new flaws should assume attackers learned from the same history.

The lack of current exploitation should therefore be interpreted as opportunity rather than reassurance. Defenders have something they rarely receive during a zero-day incident: fixes are available before widespread abuse has been reported. Check Point has issued updates and LivePatch protections for affected releases, allowing organizations to reduce exposure without necessarily waiting for a larger platform upgrade. Administrators should verify that the relevant LivePatch or fixed Jumbo Hotfix is actually installed rather than simply assuming automatic update mechanisms have completed successfully. Check Point publishes updated images and hotfix accumulators across supported R81.20, R82 and R82.10 branches, and the exact fixed build should be verified against the vendor advisory for the deployed platform.

That verification step matters because “automatic update enabled” and “protection installed” are not synonymous. Security gateways may be offline from update services, subject to maintenance controls or operating in clusters where deployment has not completed uniformly. Large organizations should inventory every gateway and management node and confirm the actual patch or LivePatch state rather than accepting a central policy setting as proof of remediation. A single forgotten appliance at a branch office can remain the easiest path into an otherwise well-patched environment.

For site-to-site VPN deployments, the Dutch NCSC also recommends reducing exposure by changing VPN rules where practical, including disabling implied rules and restricting VPN access to known peer IP addresses. This is a useful compensating control because many site-to-site tunnels connect to a small, stable set of gateways. If a firewall expects IKE traffic only from three branch locations, there is little reason to allow every internet address to reach the negotiation service. Source restriction does not fix the vulnerable code, but it dramatically reduces the number of attackers capable of sending malicious traffic to it.

Remote-access VPN deployments are more difficult because legitimate employees may connect from changing residential, mobile or travel networks. In those environments, network filtering cannot provide the same protection, making rapid patching even more important. Organizations should nevertheless review whether every exposed VPN service is genuinely required, whether legacy VPN functionality remains enabled unnecessarily and whether management interfaces are reachable through the same public path. Reducing unnecessary services is one of the few controls that permanently removes attack surface instead of merely attempting to detect attacks against it.

The NCSC warning also reinforces why network-security products need independent telemetry. Traditional organizations deploy extensive EDR coverage across Windows and Linux servers but frequently have comparatively little runtime visibility into proprietary firewall appliances. If a security gateway is compromised, endpoint agents cannot necessarily report the malicious processes or filesystem changes occurring there. Authentication, VPN, management and system logs should therefore be exported to an independent SIEM or log server so that evidence survives even if an attacker later gains administrative control of the device.

Outbound communication from VPN gateways should receive similar attention. Security teams naturally focus on hostile traffic arriving at the firewall, but after compromise the more useful signal may be traffic leaving it. A gateway establishing unexpected connections to unfamiliar internet infrastructure, initiating reverse shells or communicating with systems unrelated to its normal management and update functions should generate alerts. Network-security appliances tend to have relatively predictable outbound behavior, which can make deviations particularly valuable indicators of compromise.

Configuration integrity should also be monitored closely. An attacker with administrative or root-level access to a gateway may not need to install persistent malware if they can simply create a permissive firewall rule, new VPN configuration or hidden administrative account. Organizations should maintain known-good configuration baselines and compare current policy against those snapshots following suspicious activity. Changes to VPN peer definitions, management access, NAT rules or security policy should be attributable to approved administrative actions.

The new warning is also a useful reminder that CVSS alone cannot communicate timing. Both vulnerabilities have been 9.8 since disclosure, but their operational urgency has increased because a national cybersecurity authority now expects exploitation to emerge rapidly. The underlying code has not changed; the threat environment has. This is why vulnerability-management systems need to ingest changing threat intelligence rather than assigning a fixed priority when a CVE is first published and never revisiting it.

A vulnerability can begin as vendor-discovered with no exploitation, progress to public technical analysis, then receive proof-of-concept code, scanning activity, active exploitation and eventually ransomware use. Each stage should change the remediation priority even though the CVE number and CVSS score remain identical. Mature vulnerability management therefore needs to be continuous rather than transactional.

CVE-2026-85102 and CVE-2026-85103 are currently in an unusually important stage of that lifecycle. The vulnerabilities are known, vendor fixes exist, the systems are high-value and internet-facing, and the Dutch NCSC expects attackers to move soon, but public exploitation has not yet been confirmed. This is precisely the moment when organizations have the best opportunity to patch before the incident-response problem begins.

The broader lesson is that edge-security devices have become some of the most attractive targets on enterprise networks because they combine exposure, privilege and trust. VPN gateways must accept traffic from untrusted networks by design, they frequently sit directly between the internet and internal systems, and they often lack the endpoint telemetry available on ordinary servers. Attackers understand that compromising the system enforcing the perimeter is frequently more efficient than attempting to evade it repeatedly.

That is why the Dutch NCSC warning should be interpreted as a prevention window rather than an alarmist prediction. There is currently no public PoC and no confirmed active exploitation, but all of the ingredients for rapid weaponization are present: serious unauthenticated flaws, public patches that can potentially be reverse-engineered, exposed VPN infrastructure and a high-value post-compromise position. Waiting until exploitation is formally confirmed may provide certainty, but it also gives attackers the same time.

The preferable sequence is simpler: identify the affected gateways, verify the actual fix or LivePatch state, restrict VPN exposure where architecture permits and retain enough independent telemetry to detect suspicious activity. If exploitation eventually begins, organizations that completed those steps will be investigating attempted attacks rather than explaining why a known 9.8 vulnerability remained exposed.

Because with internet-facing VPN infrastructure, the most valuable security advantage is often not knowing that attackers have started.

It is being patched before they do.

The Dutch Nationaal Cyber Security Centrum (NCSC) is warning of imminent exploitation of two critical flaws in Check Point VPN tracked as CVE-2026-85102 and CVE-2026-85103. [...]

Source: Dutch NCSC: Critical Check Point VPN flaws exploitation is imminent via Bleeping Computer — published 12 Sep 2026.