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

[_Val_]

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

[ccsjnw]

Update - just for clarity: What surprised me was that LivePatch (something I didn't know existed) was actually already enabled and doing its thing. My confusion was a result of not knowing this, and assuming that I needed to manually enable it.

It's just the consent flags in Global Properties | Data Access Control that need to be enabled, for LivePatch to be active:


Mine were already set to the above - which means LivePatch is already enabled.

I think this could have been communicated far better - it's really not made clear in the SK articles that no manual steps are necessary to enable LivePatch, if the correct consents are ticked in Global Properties. At first, I thought the (offline) download packages for LivePatch were the packages required to install and enable the LivePatch technology - because I did not know the technology was already part of the platform.


The rest of text is from my original post, while I was still confused:

I'm still unclear with regard to the proper enablement of Live Patching...

cplp list

Why is the same CVE shown more than once and how can it have the status of both Ready and Armed?

autoupdatercli show urgent_security_updates

I see:


What do I actually need to do to make the live patches take effect?

Do I just need to issue the command:

autoupdatercli update_component urgent_security_updates

And do I only need to issue this command just once for the whole LivePatching process to automatically stay up-to-date ???

I been through various SK articles and it's still not clear to me... 


Please can the terminology be improved:


The word ARMED in this context is very ambiguous. ENFORCED would be far clearer, and not open to the wrong interpretation of the word.

According to the above, Ready means Installed and Waiting
Waiting for what target process? Can something be installed, but not active? Perhaps use the wording, Deployed, but not yet active or Deployed, but not yet enforced - it needs to be crystal clear.


I think we all just need some further clarity, as we're all playing catch up, and don't want to break anything...

LivePatch is clearly an impressive technology - thanks for the continued innovations.

[Bob_Zimmerman]

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.

[ccsjnw]

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).

[_Val_]

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

[Ambar]

Hi ccsjnw, thank you for your sincere feedback

we provide “heads up” on Darwin release by sk184735 and enhancing our visibility as you can see in sk185114

As a user you should monitor this item from MGMT and cplp list is for expert use, we will take inconsideration your insight for improvement

If patch is applicative for your system you don’t need to do anything

You may see the same CVE on several processes as it may affect them as well.

[Alex-]

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.

[Parabol]

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.

[Oliver_Fink]

Have you checked sk175504, Section (2)?

[Parabol]

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

[ZaferGr]

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)”

[RafaelBohrer]

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.

[StackCap43382]

CPLP has been updated to take 26 as issues have been found with older hotfixes:

https://support.checkpoint.com/results/sk/sk185114

https://support.checkpoint.com/results/sk/sk1000117/

[LeoLT]

Hi, 

Does anybody know how to disable a specific protection applied by CPLP?

There is a VPN that stopped working and we wonder if some of the latest CPLP protections could be related to this problem.

Thanks in advance

[ShaunRay007]

Hi LeoLT,

As far as I know, the only way is to disable the entire CPLP.

Have you solved this issue, mate?

Thanks

[jgar]

Hi there
regarding CVE-2026-85102 / sk1000117 specifically:

Does anyone know whether older SMB 700/1400 series are supposed to be equally affected by the vulnerability?
I realize those are EOL, but still a few in the field at small customers...
My problem is that Checkpoint hasn't said a word about versions prior to version R80, see the "affected versions" in the SK.
And I'm unsure whether it's just because they aren't affected, or for another reason.

Those few remaining 700 boxes all have vpn-s2s enabled with cert, but vpn-ra disabled.
I also suspect the vulnerability might be easier to exploit via RA then via S2S.
I see many attempts on them, but they are being rejected.
Whereas another client with an unpatched Spark 1535 on which both S2S & RA were enabled, was completely compromised through RA.

[ccsjnw]

If the software versions you using are no longer supported, then it’s unlikely CheckPoint would put much effort in testing this. I would presume your appliances are vulnerable unless explicitly told otherwise from an official CheckPoint source.

[PhoneBoy]

I doubt 700/1400 appliances were tested since they have been End of Support for two years now.
Having said that, I would consider them vulnerable to this CVE.