CVE-2026-85102 does not care that the federal due date was Sept. 25. Today is Sept. 29. If a Check Point gateway or a management server is still on the takes named below, the calendar is not your excuse.
BleepingComputer on Sept. 23 reported that CISA had put both flaws in the Known Exploited Vulnerabilities catalog and told federal agencies to apply the fixes or the mitigations by Sept. 25. Rescana’s Sept. 24 note says both entered KEV on Sept. 22, with forensic triage as part of closing the ticket. You are probably not a federal agency. The due date is still the signal that someone else already decided the exploit is not theoretical. We wrote the same kind of late note for the Cisco, Citrix, and Fortinet KEV batch and for the kernel deadline that ended Sept. 21. This one is a firewall and its management plane, not a node kernel.
There are two bugs. Patching one does not patch the other. That is the whole article, and the version numbers are how you prove you understood it.
CVE-2026-85102 is the VPN certificate bug
Check Point’s advisory, by Lotem Finkelstein, VP of Research, dated with the Sept. 22 post, describes CVE-2026-85102 as improper validation of certificate data during VPN negotiation. Unauthenticated remote code execution. CVSS 9.8. Products: Security Gateway, and Spark firewalls whether they are centrally managed or locally managed. The version list runs through end-of-support R81 and R81.10, the R81.10.X and R82.00.X trains, and the still-current R81.20, R82, and R82.10. Support article sk1000117 is the vendor’s own page for it.
Rescana files it as CWE-295 and says it matters when Site-to-Site VPN or Remote Access VPN is in use. If you turned VPN on because the wizard offered it, you are in scope. If you are sure both VPN blades are off and you can show that in the policy, you still patch, because “sure” and “the object is disabled” are different states. You do not get to skip a 9.8 because you think the rulebase is tidy.
Check Point disclosed this one and shipped fixes on Sept. 9. Finkelstein’s post says they had no evidence of exploitation at disclosure. They are now seeing exploitation attempts against Spark customers globally. BleepingComputer quotes the company on the start of that wave: Sept. 12, from anonymization infrastructure, VPNs and proxies. The Dutch NCSC had already warned on Sept. 10 that exploitation looked imminent. The gap between “fixed, no exploitation seen” and “Spark customers are being hit” was three days. That is the timeline to remember the next time a jumbo sits in a change window for a month.
Rescana is careful on a point the headlines blur. Vendor materials do not confirm that an 85102 attempt succeeded. Attempts are not compromises. You still hunt. You do not write an incident report that says you were owned because a scanner knocked. You also do not write “all clear” because the vendor has not published a confirmed breach of your tenant. Your logs are the only document that can say either thing.
The take that fixes 85102 is not the take that fixes the other bug
BleepingComputer’s reading of the 85102 advisory is the patch line I would put in the ticket.
On supported R81.20, R82, or R82.10 gateways, install LivePatch Take 26. Or install a fixed Jumbo: R81.20 Take 166, R82 Take 126, R82.10 Take 44, or R81.10 Take 190, or later. Spark firewalls go to R82.00.10 Build 2325 or R81.10.17 Build 4968, or later. Customers who installed an earlier offline LivePatch package still need Take 26 for full coverage. “We applied a LivePatch in September” is not a close. The take number is the close.
Verify on the gateway, in expert mode:
cpinfo -y CPupdatesRescana also mentions cplp list next to that command. I would run the vendor command first and use the second if your SK tells you to. Do not invent a green checkbox. Read the take.
If you cannot update today, BleepingComputer reports Check Point’s mitigation, and it is narrower than people will want. Disable the VPN implied rules. Write explicit Site-to-Site rules that allow UDP/500 and UDP/4500 only to the peer addresses you actually have. For Remote Access, allow only the services you need on UDP/500, UDP/4500, TCP/443, and TCP/80 where that last one applies, and restrict the source ranges. This mitigation does not apply to locally managed Spark firewalls. Help Net says the same limit: mitigation for boxes you cannot patch immediately is for centrally managed Spark, not the locally managed ones. A locally managed Spark that cannot take Build 2325 or 4968 does not have this workaround. It has an exposure, and the workaround is to get the build on it or take it off the internet.
The certificate subjects Check Point published, via BleepingComputer, are hunting clues, not a complete list:
CN=vpn,OU=users,O=global
CN=vpn-user,OU=users,O=global
CN=vpnuser,OU=users,O=globalThe company said these three reflect what they had seen, and that more subjects may be in use. If your hunt is a grep for the string O=global and nothing else, you will miss the next certificate. Finkelstein’s post tells you what the second stage looks like: suspicious logged-in users coming through Mobile Access, then internal port and service scans. Help Net’s version of the same advice is to review logs for anomalous certificate-based Mobile Access logins since the wave started. Start the review at Sept. 12, not at Sept. 25. The due date is when agencies were supposed to be done. The attempts started thirteen days earlier.
CVE-2026-93616 is the management plane, and LivePatch 28 does not touch it
The second bug is why a gateway that is “already patched” can still be the wrong sentence.
Check Point describes CVE-2026-93616 as a pre-authentication path traversal in the management web service. It can execute a script from an arbitrary path and load an arbitrary Java class. CVSS 9.8. In the wild. SK sk1000171. Finkelstein calls the exploitation a handful of pinpointed cases, and says a fix is available with this advisory. BleepingComputer says it has been exploited as a zero-day since July 23. Help Net says Check Point is aware of a handful of customers who have been attacked, and that an attacker can upload and execute arbitrary scripts on the management server. “Handful” and “since July 23” can both be true. A small number of confirmed victims over two months is not a reason to wait. It is a reason the bug was quiet enough to miss in a July log review.
Help Net’s product list is the one to paste into the inventory, because the advisory’s “Security Management” shorthand hides the cousins. Security Management Server. Multi-Domain Security Management Server. Log Server. Multi-Domain Log Server. SmartEvent. If you only patched the thing you call “the manager” and you left the log server on an old jumbo, you did not finish.
The affected takes, from Check Point’s own table: R82.20 is listed. R82.10 Jumbo Take 44 or lower. R82 Jumbo Take 126 or lower. R81.20 Jumbo Take 166 or lower. R81.10 Jumbo Take 190 or lower, and that train is end of support. R80, R80.10, R80.20, R80.30, R80.40, and R81, all end of support. Read that list next to the 85102 fix line. R82.10 Take 44, R82 Take 126, R81.20 Take 166, and R81.10 Take 190 are the floors BleepingComputer cites for the VPN bug. They are also the ceilings Check Point cites as still affected by the management bug, when the wording is “or lower.”
A gateway on R82.10 Take 44 can be done with CVE-2026-85102 and still inside the affected set for CVE-2026-93616. That is the failure mode this title is about. LivePatch Take 28 and Take 29 do not address 93616. Check Point prints that in the advisory table. Rescana repeats it and adds that LivePatch is not available for this issue. If someone in the bridge says “we pushed LivePatch 29 last week, management is fine,” they have confused the two bugs. Ask them for the jumbo take on the management server, not the LivePatch banner on the gateway.
Rescana summarizes fixed 93616 takes as at or above 45, 127, 170, and 192, depending on the train. I am not going to bless those four numbers. A plus-one on Take 44 and Take 126 would be 45 and 127. A plus-one on 166 and 190 would not be 170 and 192. Secondary writeups drift. The vendor page for the exact fixed build is sk1000171. Open it. If your take is in Check Point’s “or lower” column, you are not done, whatever a blog rounded the next take to.
If you cannot install that hotfix today, Help Net reports the mitigation that does exist: limit access to the management servers to trusted internal IP addresses. Management on the internet, with a pre-auth path traversal, is not a remote-admin convenience. It is the bug. Rescana mentions TCP/19009 in its checklist of questions for an MSP. I am treating that port as Rescana’s question, not as a vendor-confirmed sole listener. Do not build the firewall rule from this paragraph. Build it from the SK, and from the question “can an address that is not our admin network open the management web service at all?”
What to ask the MSP, and what not to mix in
Rescana’s framing is the right one if you do not run the boxes yourself. Security Gateway and Spark sit on the perimeter, often an MSP’s perimeter. Management, multi-domain, log, and SmartEvent are the control plane for a fleet of those gateways. These are two tickets. Ask, in writing:
Are the gateways and Spark devices on LivePatch Take 26, or on Jumbo takes at or above 44, 126, 166, and 190 for the matching train, and are Spark devices on Build 2325 or 4968 or later? Is certificate-based VPN in use, and has anyone reviewed Mobile Access certificate logins since Sept. 12, not limited to the three published subjects? Is management reachable from the internet, and is its jumbo above the “or lower” takes in the 93616 table? Did anyone mistake LivePatch 28 or 29 for a fix of the management bug?
Same Tuesday, Help Net notes, CISA also added CVE-2026-93952 in Arista’s VeloCloud Orchestrator and CVE-2026-94127 in F5 BIG-IP APM, the latter an unauthenticated remote code execution if the box is configured as an OAuth authorization server. Those are not Check Point steps. Do not close them by installing a Check Point jumbo, and do not let a Check Point change window consume the week so thoroughly that the F5 OAuth configuration goes unexamined. Different vendor, different ticket, same KEV date.
I am not giving you an exploit. The vendor already told you the bug class, the takes, the three certificate subjects they have seen, and the second-stage shape. Your job is the boring one. Run cpinfo -y CPupdates on the gateway. Read the management jumbo. If Take 44 is your idea of “current” on R82.10, you fixed the VPN story and you left the management story open. sk1000171 is the page that says what “fixed” means for that second story. The Sept. 25 date will not move because you found this article four days late.
