CVE -2026-85102 is now being actively exploited against Check Point Spark Firewalls, according to the company itself. The critical vulnerability allows a remote, unauthorized attacker to execute code via the VPN negotiation process, without having an account on the system. The development mainly affects devices exposed to the internet for remote access.
Check Point's update says the first attempts were detected on September 12, while the company had been releasing fixes since September 9. CISA added the CVE to its Known Exploited Vulnerabilities list, increasing pressure for immediate action.
See also: Check Point VPN vulnerabilities: NCSC warns of imminent exploitation
CVE-2026-85102 in Spark Firewalls
The vulnerability is rated CVSS 9.8 and concerns insufficient validation of certificate data during VPN negotiation. When the device processes the identity of a remote VPN node, specially crafted data can reach a sensitive path before authentication.
The result is remote code execution on the Security Gateway. The attack does not require any credentials or user action and targets installations with Site-to-Site VPN or Remote Access VPN. Because the device is located at the network perimeter, a successful compromise can provide access to settings, connections, and subsequent internal steps.
According to the official advisory sk1000117, versions R81, R81.10, R81.10.X, R81.20, R82, R82.00.X and R82.10 are affected, along with older versions that have reached end of support. Centrally and locally managed Spark Firewalls fall into the same category.
CVE-2026-85102 should not be confused with the separate CVE-2026-93616 vulnerability in a management service. Both cases appear in the same advisory, but have a different mechanism and a different bulletin. The SecNews technical team recommends that both be checked only when the corresponding products are present.
The initial disclosure was made on September 9, when Check Point said it had no evidence of exploitation. Three days later, attempts were reported against Spark customers, and on September 20, the advisory was updated with more guidance for LivePatch. The sequence shows how quickly the assessment of a flaw in a network device can change.
Signs of attacks and immediate actions
Check Point says the attempts originated from anonymization infrastructures, such as VPN services and proxy servers. Certificates with the CN=vpn, CN=vpn-user and CN=vpnuser, but this is not a complete list. Administrators should also look for unusual Mobile Access connections, suspicious logged-in users, and internal port scans.
The priority is to install Check Point LivePatch Take 26 or the corresponding Jumbo Hotfix, depending on the version. The advisory indicates as indicative safe versions R81.20 Take 166, R82 Take 126 and R82.10 Take 44 or later. For Spark Firewalls, R82.00.10 Build 2325 and R81.10.17 Build 4968 or later apply.
Where the update cannot be applied immediately, Check Point recommends temporarily disabling the default VPN rules and creating explicit rules. For Site-to-Site VPN, access to UDP/500 and UDP/4500 should be restricted to known VPN partner addresses. For Remote Access VPN, restrictions on allowed services and user address ranges are required.
In environments with multiple devices, control should not be limited to a central management system. Administrators need to record which gateways are terminating certificates, which are accepting connections from the internet, and which are running older software versions. This avoids leaving a less visible part of the infrastructure exposed.
See also: Check Point Management Server: Critical zero-day in targeted attacks
See also: Critical vulnerability in Check Point management allows code execution
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
Given the active exploit, simple monitoring is not enough. Organizations should confirm the exact version and VPN profile of each device, apply the fix, check logs for the above patterns, and re-examine connections that occurred after September 12. After installation, confirmation of the take or build number is required, as well as verification that the service is operating according to the intended rules.
Security teams should maintain a copy of relevant logs prior to any changes so they can compare activity before and after the update. If suspicious connections are detected, the investigation should be expanded to Mobile Access accounts, new rules, outbound connections, and scans from the gateway to the internal network.
