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 

[freshwater84]

Seems not - guess 118 is not recommended...?

[Joe_Kanaszka]

Not sure..maybe its not a major Take...

[Joe_Kanaszka]

Thanks Dan - I'm trying to take baby steps as the last thing I want to do is cause an outage that I cannot easily back out.  🙂

[Dan_Moesch]

That is exactly why I recommend the patch. 

Just take a snapshot of your existing gateway, run the patch.

If there is an issue you can reboot to the snapshot.  Every other scenario seems like it will cause issues.   We updated 4 HA clusters last night without issue. 

The thought of changing VPN settings with live connections is rather impactful vs applying a patch that can be rolled back in minutes.   

[Joe_Kanaszka]

Is there a patch for R81.20 Take 118 or would we need to first upgrade to one of the patch takes?

[Duane_Toler]

 No, not for JHF 118

You'll need to go to at least JHF 120, but might as well just go to 141 and be done with it.  There are a ton of fixes between 118 and 141.  If you have any custom hotfixes for your JHF version (like I do), then you'll need to make some choices. You still can open a TAC case to have R&D get you a portfix for those.

I've done that for my batch of fixes (many, many, many times).

Screenshot 2026-06-09 at 3.22.26 PM.png

[Joe_Kanaszka]

So just so I understand you, you've requested TAC to create a hotfix for your particular Take correct?  So I can request one for Take 118?  

[Duane_Toler]

If you have a custom hotfix that is restricting you from updating past your JHF 118, then yes.  You need the CR ID for that hotfix, or just give them the hotfix patch from "cpinfo -y all" if you know it.  It'll be something like "HOTFIX_R82_JHF_T91_252_MAIN".  That "JHF_T91" is Jumbo HFA 91 and the "252" part is the custom hotfix number for it.  Better yet, having the CR ID (which you generally have to request when you get the hotfix) is more helpful for them to look it up.

For example, that hotfix is PRJ-63910 for the "show-tasks" API that has a bug with historical task filtering when using either "admin-name" or a fixed date range.

Anyway, you get the idea.

HOWEVER.. if you're asking them to create a CVE patch just for JHF 118, that's probably unlikely to happen.  Maybe they will, since they also did 113.  Who knows.. maybe you'll lucky! 🙂

[Duane_Toler]

I would suggest you start a new CheckMates thread for this, that way in the future someone with a similar problem can find yours easier and hopefully whatever solution comes out of it.

[Joe_Kanaszka]

Will do!  Thank you Duane.

[Joe_Kanaszka]

ok. I’ve noticed something after trying Option 1 and disabling “Older Clients”, implementing the reg hack and enabling in Global Properties “Enable  IKE 2 and support IKE 1 (I chose this one). I’m still seeing the same IKE errors in Smart Log. After I revert all the changes to get my clients working again, before my client works, I need to switch the authentication in the client settings to DUO instead of DUO default.  Might there be something here I’m overlooking??

[Duane_Toler]

Use the multiple login options ("authentication profiles"), add one named Default and configure it as based on "username password", edit that profile, then change the method to use RADIUS and choose your RADIUS server group for the Duo hosts. Click OK. Then on the left, for User Directories, enable the Authentication Units for your AD servers and choose the correct username format (UPN or sAMAccountName).  This links your Duo RADIUS servers and the username lookup to AD.  Uncheck "internal users" here, too.
If you do it this way, you won't need the "generic*" wildcard user anymore.  You can then have separate locally-defined ("internal users") as your break-glass backup.  Do this with a new authentication profile (name it something diferrent; "Administrator Login" or whatever), that is based on Username/Password and binds to just "internal users" only; no AD and no RADIUS.

The first profile in the list (Default) will be used by the VPN clients by default.  It shouldn't cause an interruption in your clients.  If it does, then prepare a HOWTO document to have a client select the default logion option in the UI.

This is all out of scope for this thread, however, and I believe there are other existing CheckMates threads about this, as well as the Remote Access VPN admin guide documentation (page 43, for R81.20 and R82).

[Joe_Kanaszka]

Thank you!  Trying now!!  

[Duane_Toler]

Keep in mind, I made a LOT of assumptions about your configuration!

[Joe_Kanaszka]

Ugh - still does not work.  Get the Duo push but right afterwards get kicked out.  IKE errors in Smart Log.  

[Joe_Kanaszka]

Good morning again Duane.  Forgot to ask the obvious question:  Why do you need to configure Duo this way in the multiple authentication types section?  For instance, not simply choosing Radius from the drop down but rather username and password and then Radius?

[Duane_Toler]

That's a fair question!  The name of the "authentication factor" is "Username_Password", then you can edit that factor's option and select RADIUS as the method of obtaining and verifying the credentials.

By default, you only get 3 preconfigured factors (but you can certainly make more, and many places do).  The quickest-and-easiest is to just pick one of the defaults, tho:

Screenshot 2026-06-22 at 10.39.15.png

Then configured the methods for that factor profile:

Screenshot 2026-06-22 at 10.40.15.png

The "Display Name" is what the client sees in their own Multiple Login Options drop-down selector.

[Joe_Kanaszka]

Gotcha! - so even if we only have one "method" in the Authentication Methods section, this still is the preferred way to configure Radius authentication?

[Duane_Toler]

Yep, and it lets you turn off that top "allow older clients" checkbox, plus you can abandon use of the "generic*" user as well as any per-user methods.  Be sure you also enable "Remote Access" as an Identity Awareness source.

As a bonus, then you configure your users in the policy with Access Roles instead of "Users@Any" "legacy" method, AND you can drop "RemoteAccess" from the VPN column.  If you have Identity Collector (or any other identity source), then this doubles-up to integrate with that as a single authentication rule.

If you set the "Display Name" to "Default", it should be a non-event on the clients.  Internally, for the single authentication method, the client names its one-and-only profile "Default" ( i saw this in the client-side trac.config file).  I haven't 100% verified this universally, tho, so proceed with caution until you can confirm it.

[Joe_Kanaszka]

Makes sense.  Thank you again Duane!

[ANARINE]

how did you revert?

[Joe_Kanaszka]

I didn't install the hotfix - just option 1 from the SK.

[J_admin12]

The blopost about this Advisory seems to have one set of IOC attacker IPs and then the SK is not alligned to this.

So which one should we be checking for updates, surely they should both be consistent.

It would also be great to have a changelog on the SK so we know if updates are posted on it.

The specific R81.10.17 / R82.00.10 are not updated to include the latest build to protect against this CVE either.

[Arskazv]

Hi!

Just a question:

If attacker is not a member in any allowing remote access rule, does he still have access to internal resources?

So any deeper details available?

I haven't seen any discussion about this? 

BR, A

[PhoneBoy]

Actual access to internal resources would be dictated by the rules you've defined, yes.

[freshwater84]

Would that be also valid for AccessRoles related to internal or LDAP users with personal certificate needed from the VPN authentication rulesets?

We patched already, but still interested in the topic

[PhoneBoy]

I'm not sure if the exploit results in a username that could be looked up via LDAP (e.g. to calculate an AccessRole that would permit access to more than "any" user would).
I'll see what I can find out.

[StackCap43382]

What is the recommendation for patching to the latest jumbo with the integrated fix when the IKEv1 hotfix was installed ontop of a previous jumbo?

Is it to install over the top or remove the IKEv1 hotfix before patching?

[VikingsFan]

Following.  I've always heard to remove the hotfix and then install the JHF but have not seen anything specifically documented.

[StackCap43382]

I just labbed installing 146 over 141 + IKEv1 hotfix and it worked but with a "quirk" 

After hitting install the DA changed package state to "downloaded" and sat there.

Checked the installer log file and the patch was installing while in the "downloaded" state

Rebooted and came up as 146.

The 141 hotfix is still showing in the list:

This is Check Point CPinfo Build 914000274 for GAIA
[FW1]
HOTFIX_R81_20_JHF_T141_HF2_MAIN Take: 2 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
HOTFIX_INEXT_NANO_EGG_AUTOUPDATE
HOTFIX_TEX_ENGINE_R8120_AUTOUPDATE
HOTFIX_R80_40_MAAS_TUNNEL_AUTOUPDATE
HOTFIX_GOT_TPCONF_AUTOUPDATE
HOTFIX_R81_20_JUMBO_HF_MAIN Take: 146
HOTFIX_PUBLIC_CLOUD_CA_BUNDLE_AUTOUPDATE