Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
_Val_
Admin
Admin
Jump to solution

[Action Required] - Critical Security Advisory: VPN Vulnerabilities CVE-2026-85102 and CVE-2026-8510

Hey CheckMates

Check Point research team has identified and remediated two critical VPN-related vulnerabilities, CVE-2026-85102 and CVE-2026-85103, which could potentially allow unauthenticated remote code execution under specific conditions. These issues were discovered internally, and we have no indication of active exploitation.

To ensure continued protection, we strongly recommend installing the latest Jumbo Hotfix for your deployed version as soon as it becomes available.

Please note that customers using Check Point Live Patch will be automatically protected as the rollout begins on September 9, 2026. If you are not using Check Point Live Patch, read sk185114 for more details on how you can benefit and stay protected.

For detailed information, affected products, mitigation guidance, and remediation instructions, please refer to the following Security Advisories:
  • CVE-2026-85102: Authentication Bypass and Remote Code Execution in Remote Access and Site-to-Site VPN - sk1000117
  • CVE-2026-85103: ASN.1 Decoding Heap Overflow Leading to Remote Code Execution - sk1000118
98 Replies
Bob_Zimmerman
MVP Gold
MVP Gold

Based on your 'cplp list', the live patch is already present and working on that system.

For ready versus armed, consider a firewall where you have the IPSec VPN feature unchecked. That would mean right now it wouldn't run iked, vpnd, and so forth, so there are no processes to patch. If you then check the IPSec VPN feature, use the firewall in a VPN community, and push policy, it would start various VPN-related processes. CPLP is watching for those processes to start, and it will attempt to patch them if it sees them.

Ready means it's ready to patch the processes if you enable the feature. Armed means it has detected relevant processes and patched them in RAM.

Agreed that the wording could be better. The state currently described as 'ready' seems more reasonably 'armed' to me: the system is prepared to take action, but hasn't taken any action yet. Like an alarm which is armed, but not firing. That said, the current wording is at least used consistently, which matters more than picking exactly the right words.

(1)
ccsjnw
Collaborator

Thanks for the clarification - that makes sense now, as this particular Security Gateway doesn't have the IPSEC VPN or the Mobile Access Blades enabled (I have already installed the latest Jumbo Hotfix Accumulator on the Security Gateways that do).

0 Kudos
_Val_
Admin
Admin

@ccsjnw thanks for your feedback. I would ask you to open a new thread so we can discuss it separately from CVE communication.

0 Kudos
Alex-
MVP Silver
MVP Silver

Uploaded two Spark Pro, 1800 and 1900 clusters today from R82.10.10 2242 to 2325, centrally managed by Smart-1 Cloud.

No issues with both 1900. Doing one of the 1800, it worked but after rebooting, policy install fails and it reports management unreachable. Clustering works. After rebooting it, it reverted to 2242. Will try again later.

0 Kudos
Parabol
Collaborator

Hi all, doing the livepatch checks, I can see that the CVE is protected on our management server and various gateways.
Annoyingly though this doesn't seem to be the case on our perimeter firewall, the only firewall using vpn's.

So I'm assuming we have to apply the hotfix. I am unsure why livepatch seems to be installed on some of our gateways but not others.

 

0 Kudos
Oliver_Fink
Advisor
Advisor

Have you checked sk175504, Section (2)?

0 Kudos
Parabol
Collaborator

I think we found the issue, the download and install fields and set to false for auto_updater:

autoupdatercli show auto_updater

product-name: deployment_products

component-name: auto_updater
component-branch: Infra_AutoUpdate
GA-Version: 0
download-scheduler-active: false
install-scheduler-active: false
download-action: idle

Trying to enable causes some error about DDR:

autoupdatercli enable auto_updater
Failed to change state for component auto_updater to on: The component auto_updater is disabled by DDR and cannot be enabled.

We found sk184657 but the solution talks about ""This will result in a re-evaluation according to the Dynamic Deployment Rules" so I am wary whether this could cause some impact if we apply on our perimeter firewall.

I have raised a ticket with TAC just to be sure. And we are applying the JHF in the mean time

0 Kudos
ZaferGr
Participant
Participant

If you receive a “failed to import package” error during installation,

you can try this SK;
SK185114 - Check Point Live Patch (CPLP) under “Installation Procedure for Offline Package (Single Machine)”

0 Kudos
RafaelBohrer
Participant

Hello. Anyone have some issues after applying Take 44 with Remote Access using Endpoint Security VPN Client?
After install, remote users no longer connect to the gateway. 

The client takes too long time in "Detecting site connectivity" and then "Retrieving site information".

There is no problem with the link and nothing was changed in the configuration. Only affects Remote Users VPN.

Regards.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events