There is a specific kind of bad day in security: the one where the fix already existed, the attackers knew it, and the only thing standing between them and your network was a maintenance window nobody scheduled.
That is where Check Point customers are sitting right now. On September 22, Check Point Research published an action-required advisory confirming active exploitation of CVE-2026-85102, a pre-authentication remote code execution flaw in the VPN certificate handling of Security Gateway and Spark Firewall. The patch for it shipped on September 9. Exploitation attempts started on September 12. The gap between "fix available" and "attacks in progress" was three days.
What is actually broken
CVE-2026-85102 is a certificate validation failure in the VPN negotiation path, scored CVSS 9.8. The gateway does not properly validate key certificate data presented by a peer during negotiation. Because the flaw triggers before authentication completes, an attacker does not need a username, a password, or a session. They send a crafted certificate, push the negotiation far enough, and get code execution on the appliance itself. Affected versions span R81.10.x through R82.10, across Security Gateway and both centrally and locally managed Spark Firewall deployments.
The second flaw, CVE-2026-93616, is a pre-authentication path traversal in the Check Point Management web service. It lets an attacker execute a script from an arbitrary path and load an arbitrary Java class. Check Point observed a handful of pinpointed attacks against it on July 23, and the fix landed with this advisory. Note the detail that stings: LivePatch Take 28/29 does not address it.
The part that should worry you
This is not a theoretical "researchers demonstrated" story. Check Point published the certificate subjects its telemetry caught in the wild:
CN=vpn,OU=users,O=globalCN=vpn-user,OU=users,O=globalCN=vpnuser,OU=users,O=global
Those attempts came from anonymization infrastructure: VPN services and proxies, the usual laundering layer. The follow-up behavior is the tell that matters. After a suspicious Mobile Access login, the observed second stage is internal port and service scanning. Somebody gets in through the perimeter, then starts mapping what else is reachable.
And the perimeter is exactly where a pre-auth RCE is most expensive. Your VPN gateway is not an app behind a WAF. It is a purpose-built appliance sitting on the trust boundary, usually peered into your identity provider, your internal management network, and sometimes your directory. Code execution there is not a step toward privilege escalation. It is usually already past the wall.
Three days is the new forever
The timeline deserves a cold look, because it is the real lesson:
- September 9: Check Point discloses CVE-2026-85102 and releases fixes. No exploitation observed.
- September 12: A wave of exploitation attempts begins against Spark customers globally.
- September 22: An action-required advisory confirms in-the-wild attacks.
That is a two-week window from disclosure to confirmed exploitation, and only three days from patch to attack. Any organization still running a maintenance cycle longer than that is running an exposure, not a schedule. The public proof-of-concept economy and automated scanning are simply too fast now for quarterly patching to be a strategy.
What to do this week
If you run Check Point Security Gateway or Security Management, treat this as an incident-response posture change, not a patch ticket:
- Install the fixes now. CVE-2026-85102 is covered by the September 9 release; CVE-2026-93616 requires the Jumbo Hotfix takes named in the advisory (R82.10 Take 45+, R82 Take 127+, R81.20 Take 167+, R81.10 Take 191+) or the newer build listed in sk1000171. Skip LivePatch Take 28/29 for the management flaw.
- Hunt your Mobile Access logs. Look for anomalous certificate-based logins, and do not limit the search to the three subjects above. The list is explicitly not exhaustive.
- Chase the second stage. For every suspicious logged-in user, look for internal port and service scans originating from that session. That pattern is how you tell a blocked probe from a foothold.
- Inventory the EOS tail. R81 and R81.10 are end-of-support and still in the affected list. If you have appliances in that tail, you are running a system nobody is shipping fixes for by default. Plan the replacement, not just the hotfix.
- Assume negotiation-phase bugs are recursive. Every VPN and TLS appliance you own validates certificates somewhere. Ask your vendors the uncomfortable question: what happens when that validation fails open?
The takeaway
The attackers did not need zero-day magic for the main event. They used a bug that had a fix, an advisory, and a two-week head start. The organizations that get hurt here are not the ones with the weakest tooling. They are the ones whose change management treats a 9.8 perimeter RCE as a routine line item.
Patch now. Then go read the logs. The scans are the part of the story you can still catch.