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 

[BAlexiev]

Hi, Duane,

"You either need a newer client that supports IKEv2 out-of-the-box" - AFAIK there is no such version for now and sk166415 is valid for all E89.x versions. Do you have other information? 

[Orel_Vanounou]

• The client-side Registry changes per sk166415 is required as follow:
  • Windows clients - all versions, including the latest available
  • MAC OS clients - only from E88.40 (including E88.40) and until E89.X (not including E89.X)
• Firewall side configuration remains needed in all use cases (IKEv2 only)

[ANARINE]

Does IKEv2 require R82 or higher ?

[BAlexiev]

R82 is required for Remote Access VPN using IKEv2.
It is not required for Site-to-Site VPN with IKEv2, which is supported in R77 and R80.

[Orel_Vanounou]

Remote Access VPN clients support IKEv2 starting from Endpoint Security Client version E88.40 and Security Gateway version R82.

[ccsjnw]

But only with the Registry Hack. So *not* supported natively out of the box, and only supported with a stupid manual workaround.

There’s a trend where CheckPoint are being economical with the truth with this whole IKEv1 situation.

[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 ?

[PhoneBoy]

There are some non-EOL appliances (Spark/SMB) where R80.20.x is the most recent release, which is why we have released a version with this fix included.
The CVE likely exists in earlier versions.
Not aware of any plans to offer patches for EOL versions beyond what we've already issued.

[Duane_Toler]

On my Mac, at least, I had E88.70 and got refused to connect to an IKEv2-only gateway.  I downloaded and installed the latest E89 client and it worked out-of-the-box with no customizations.  Might be Mac-specific behavior, tho.

[Alex-]

Yes, it is. The SK states that Mac clients using E89 and upwards do not need the registry hack.

Which asks the question why not Windows.

[Duane_Toler]

Without the registry edits on Windows, a delete/re-create of the site was not sufficient either.  My teammate tried that and didn't work.

[Alex-]

Correct. The SK is clear on this.

Windows: hack required at all times + change of GP for RA.

MacOS: No hack for E89+ and change of GP for RA.

[Paul_Stephenson]

Why is this not yet the default on Windows?

The wording on the communicated specifically throwing in that IKEv1 is deprecated makes it sound like we should not be using it, whilst all over the Check Point product its warning us not to use IKEv2 else clients won't connect! And indeed won't without a registry hack.

Is the IKEv2 support flaky/not recommended? If not, enable it by default???

And on the registry hack note, it would be great if options like these and trac settings moved into a centralised area for management, such as the Check Point Portal for example.

[Duane_Toler]

Yep, and you get warnings all over the place when you turn off 3DES and MD5/SHA1, too.  Be sure you enable AES-256 and SHA-256, then select those in the drop down boxes, and click "OK OK OK OK" at all the warnings.  Be sure you do both the IKE and IPsec tabs.

Yes, you'll probably bump some clients; hopefully you have a way to update your fleet OoB, too.

[ccsjnw]

Well said Paul. I totally agree 👍 

IKEv2 support for Windows Remote Access VPN Clients has been handled extremely poorly. I have been chasing them about the Registry Hack for ages and ages without progress. I suspect this debacle will finally see this long standing issue get resolved!

[Alex-]

The issue in the wording is that this "deprecated" protocol can only be improved with RA as of R82 which is quite recent in the grand scheme of things. R81.20 is still widely used, so suddenly does it mean it completely becomes "deprecated" as well?

IKEv2 has been in IPSEC since a while, like GCM (asked by quite a few customers). The VPN client should have been updated to support IKEv2 natively since quite a while if this was such an issue.

I'd rather have seen wording simply explaining the vulnerability in the system, which can absolutely happen, and focus on fixing it, without some low-key finger-pointing.

[Harel-Zar]

Hi we have the latest Harmony Client 89.10.0370 and the registry was on disable_ikev2=1
i had to change it and reboot for ikev2 to work 
i add a new Group Policy Objects and force it on all the domain

[hvf3000]

Is the fix for EOS versions such as R81.10 or even R82, with other takes beyond those listed, on the roadmap? Or will it be only for the ones mentioned in the sks?

[Orel_Vanounou]

A bundle is planned for R81.10, no ETA yet and customers should apply the available mitigation steps in between.

[ccsjnw]

When exactly did CheckPoint determine IKEv1 was deprecated?

Frankly, I think this a rather disingenuous considering that the very latest E89.10 release of the Remote Access VPN client for Windows *can’t* use IKEv2 without a Registry Hack. I’ve been quite vocal about the lack of IKEv2 support for quite some time (years!), and suddenly CheckPoint are saying IKEv1 is deprecated and now they are signaling that only customers who have been slow to adopt IKEv2 are vulnerable to this problem…

The narrative isn’t very honest in my opinion.

[freshwater84]

Be happy, if it works at least.

We tried R89.11 and R89.20, and IKEv2 in GP of R82.10 T19 + Reg-Hack does not even work... 😞

[Harel-Zar]

you must restart pc after reg change
then it will work

[GHaider]

restarting the service "Check Point Endpoint Connect" also works, no need to reboot

[Dan_Moesch]

Why not just install the patch?  We updated all of our external gateways with the patch yesterday.  

[freshwater84]

Because for several examples:

SPARK upgrade management in Smart-1 Cloud is a pain...
Full GAIAs have sometimes Hotfixes, where a PortFix needs to be developed first, which takes now most likely 5x longer, than normal, with this incident...

[Dan_Moesch]

Well that is a problem in itself, should be easy to apply vendor security patches as quickly as possible.  I guess we are in a good state where this is easily possible.  Snapshot, patch, reboot....if issue roll back to snapshot.   Seems a lot easier then what I see on this thread.   Good luck!  The workarounds provided aren't really feasible in my opinion so we went straight to patch

[Paul_Stephenson]

I think the point here is that if IKEv2 was enabled by default we wouldn't have even needed a patch install, it would have been as simple as going to global properties and moving to IKEv2 only.

Bear in mind some people may have many many gateways and they might not be HA so this means an unplanned outage.

[Joe_Kanaszka]

Afternoon all - 

We're still running R81.20 Take 118 with plans to upgrade in the fall to R82.x

All users running Windows 11 23H2 with Check Point Mobile E89.x

We are trying option 1 in the remediation article - Disable "Allow older clients to connect to this gateway"

Using Duo Radius proxy server to authenticate clients.

After configuring the "Multiple Authentication Clients Settings with our DUO Radius server - the same one that we were using in the "Compatibility with older clients section" - that we disabled, we can no longer connect. When we try and sign in to Check Point with the Mobile client, we input our username and then password, we then receive a Duo push. Immediately afterward we receive this error: "Negotiation with site failed" "Please provide a user name and password to authenticate"

In the logs, I'm seeing IKE errors:

Screenshot 2026-06-09 134812.jpg

Thank you!
 

[Dan_Moesch]

Why not apply the R81.20 patch?

[Joe_Kanaszka]

I would rather at least for now make changes that I can roll back easily - although if this proves to burdensome we may just roll out the patch.  But - is there a patch for R81.20 Take 118?