ACTION REQUIRED – Active Exploitation of Check Point VPN Authentication Bypass (CVE-2026-50751)

[_Val_]

Check Point Research has identified active exploitation of CVE-2026-50751, a critical authentication bypass vulnerability affecting Check Point Remote Access VPN and Mobile Access deployments configured to use the deprecated IKEv1 key exchange protocol.

By exploiting a logic flaw in certificate validation, an attacker can establish a VPN session without possession of a valid password, effectively bypassing authentication requirements.

Additional post-authentication activity is required to access internal resources or escalate privileges.

To date, the observed exploitation has been limited to a few dozen targeted organizations globally. One case involved confirmed post-compromise activity associated with Qilin ransomware affiliate.

Customers using IKEv1 key exchange protocol are strongly encouraged to apply the available security updates immediately.

 

CVE Details

CVE-2026-50751 is an authentication bypass on VPN Remote Access and Mobile Access in deprecated IKEv1 key exchange. An attacker can bypass user authentication by exploiting a logic flow weakness in the Remote Access and Mobile Access certificate validation and establish a remote access VPN connection without a valid user password. Check Point has observed active exploitation of this vulnerability in the wild.

Enhancing Security with BLAST (Check Point’s Agentic AI Code Security Platform)

As part of the CVE-2026-50751 investigation, Check Point Research conducted an extended review of the affected VPN components using BLAST, our agentic application security platform. This process identified and enabled the remediation of an additional vulnerability, CVE-2026-50752.

CVE-2026-50752 impacts certificate validation in deprecated IKEv1 key exchange and may allow man-in-the-middle interference with site-to-site VPN communications under specific conditions.

Check Point has not observed exploitation of this vulnerability in the wild; customers are advised to apply updates to mitigate potential exposure.

The identification of CVE-2026-50752 underscores the importance of combining threat intelligence, security research, and AI-assisted code analysis to proactively detect and remediate vulnerabilities before they can be weaponized.

For more details, please read the relevant blog entry.
 
Additional technical information, suspicious IPs, and indicators can also be found on the security knowledge base articles here: 

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

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

[Timothy_Hall]

The two SKs are coming up for me now signed in with a partner account, albeit slowly.

[CheckPointerXL]

still not clear if option 1 fix the cve totally

some notes are specified at the end of the option 1, so i'm not 100% sure

[Dan_Moesch]

Your best option is to apply the update that will show up on your gateways.  It looks like there are installs for the latest few takes-we are R82 so you can see T91 and T103 options

IKEv1-patch.png

[Alex-]

We don't know yet what the hotfix does.

If it allows the use of IKEv1 and the "unsafe" parameters, then fine, if it breaks them, it will be a problem for organisations having to switch to IKEv2 in a hurry.

It should be clearer to know if we can live with one of the 3 options as sufficient workaround for the time being. Patching systems is another ride than just changing options in SC.

[JanVC]

sk166415

IKEv2 is only supported for R82 gateways and clients starting from E88.40, seems like important information for workaround #2

[GHaider]

---

@JanVC wrote:

sk166415

IKEv2 is only supported for R82 gateways and clients starting from E88.40, seems like important information for workaround #2

---

...and even in this version i would be really careful, because i have an open case with TAC since more than 6 month, because IKEv2 is not working in my setup (R82 + Endpoint E89.10)

[freshwater84]

Here the same! E89.11 and R82 as well as R82.10 stucks forever on Authentication without error.

https://support.checkpoint.com/results/sk/sk166415 Regkey applied (and Global Properties Setting of course)

[ccsjnw]

You need the poorly documented Registry Hack for your Windows clients…

And when IKEv2 is enabled, it means the Clients can only connected to Gateways supporting IKEv2 as enabling IKEv2 on the client, disables IKEv1 support (again, not obvious from the published information).

[freshwater84]

To be honest, that I cannot confirm.
I can still connect to IKEv1 Gateways with E89.11 and 89.20, when IKEv2disable registry value is set to 0

[ccsjnw]

Sometimes you’ll find you can connect once, but not again, because the client Topology gets updated when you connect (after the Firewall policy has been installed). I’ve experienced this first hand.

[freshwater84]

Thats BAD

Checkpoint has to do something about this chaos!

Its long time not funny anymore.

Documentation as well > crap

[Sbolton]

Yes, you have to be on R88.70+, the firewalls need to be on R82, and you need to do a Regedit on your PC's to allow Ikev2. This setting currently reverts when you update the client. So just be aware.

[Dan_Moesch]

Since its not clear, the best option is to patch, which is why I suggested that.   We have way too many VPN clients connecting to safely change the IKE setting.  I have successfully applied the patch and no issues so far.

Its typically always best practice to apply vendor patches, if possible, then use workarounds.

[Alex-]

That's the issue, it's not clear enough. Wee manage a bunch of customers all around the country with various change management methods, we need to be able to evaluate if we urgently need to activate escalation at both our company and customers since it's evening here, r if Option 1 - 3 are sufficient workarounds to make this in a phased approach.

[Fastforza]

I completely agree with Alex here.

Please give us more information if we should do only Option 1 to Option 3 workarounds, or to just apply the hotfix.

[freshwater84]

As far I understood, ANY of the three mitigations solve the problem, OR just the hotfix

[Duane_Toler]

The hotfix definitely will address the issue.  According to the list of requirements at the top of the article, all of those are required so any of those mitigations will buy you some time.

[Tomer_Noy]

The various mitigations in the SK are meant to "buy you time" if you cannot install the hotfix.

Installing the hotfix is the safest and most recommended method. Both from functionality perspective and security.

The mitigations will be helpful to block the known active exploitations, so they are a great option if you cannot patch, but indeed they may require changing functionality or may impact certain client types. Also, they are potentially less "hermetic" at solving the vulnerability.

[freshwater84]

We just installed Hotfix on R82.10 Take 19 for 3900series.
VPN Dial-In with IKE1 still works
We tested to switch before applying the hotfix (with Windows RegKey from and GlobalProperties Setting) to IKE2 with Windows Mobile VPN Client E89.11 according to https://support.checkpoint.com/results/sk/sk166415

Does not work at all, Authentication stucks (we use Personal Certificate+User/Password). Sent the logs from the client to TAC.
Anybody knows, what could be the problem there?

[Orel_Vanounou]

Please submit a Support Service Request, so we can further review it.

[freshwater84]

Already done yesterday, no response so far.

[Orel_Vanounou]

Thanks for the update. Please share the SR# in private.

[GHaider]

i see exact the same behaviour with R82 and E89.05/89.10... have open a case with Support since sep. 2025 (SR: 6-0004378012), still no outcome...

[ccsjnw]

You need to deploy the Registry hack to all of your Windows Remote Access VPN clients to allow them to use IKEv2.

(This really shouldn’t be necessary when CheckPoint claim IKEv1 is deprecated - but this is still true for the very latest version of the client). Please complain to CheckPoint.

[Duane_Toler]

Oh wow! That is quite a challenge for many!

In the meantime, the hotfix should be enough to patch the issue while folks get their clients updated, and/or apply at least 1 of the mitigations to buy some time.

[freshwater84]

Still does not work with RegHack 😞
TAC ticket open

[Joe_Kanaszka]

This is my reason as well.  

[Tomer_Noy]

The best way to be safe from the vulnerability is to install the hotfix on your gateways.

The hotfix patches the vulnerability without losing functionality or breaking things that were supported before.
To be even clearer: the hotfix does not remove support for IKEv1 and you can continue to use it after installing the hotfix.

IKEv2 is a mitigation for those who cannot install the hotfix.

In general, it's recommended to migrate to newer encryption (IKEv2 over IKEv1), but it's not required to use this hotfix.

[ANARINE]

Will hotfix be released for R80.30 or R80.40 ? 

I see that R80.20 and R80.40 are vulnerable but not R80.30 ?

[Duane_Toler]

FYI:  client's E88.7x "support" IKEv2 but they don't, without the registry hacks.  You either need a newer client that supports IKEv2 out-of-the-box, or do the registry hacks in sk166415:

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

Step 1 - Enable IKEv2 in the Policy

Log in to the SmartConsole.
In the Menu, click Global Properties.
Global Properties window appears.
Click Remote Access > VPN - Authentication and Encryption.
In the Encryption Method, select IKEv2 only or Prefer IKEv2, support IKEv1.
Click OK.
From the top of the page, click Install Policy.


Step 2 - Configure the Endpoint Security Client Devices

For Windows devices:
  Open Registry Editor.
  Go to this location: HKLM\SOFTWARE\WOW6432Node\CheckPoint\TRAC
  Configure disable_ikev2 to 0.
  Restart the device.

For macOS devices:
  Open Registry Editor.  << no; Macs don't have a registry editor.
  Edit the HKLM_registry.data file.
  Change disable_ikev2 from 4[1] to 4[0].
  Restart the device.