CVE-2026-50751 - Help with some questions.

[sx8n20394]

I have contacted Checkpoint support about these questions but the low level guys have no answers for me.

Are there SHA1 or SHA256 hashes for the malicious files that were found? Our EDR doesn't allow MD5, only SHA1 and SHA256.

Is there anyway of using IKEv2 on R81.10.17 Build 4901 (Newest with Patch)? We just get the error no response from gateway for 1st packet. We updated clients to the latest version and enabled ikev2 in the registry and still get the error. Only r82 gateways work with clients using IKEv2.

We suspect 2 clients were exploited. We see no additional activity after exploitation. It looks like they successfully logged into the VPN and then the connection terminates exactly an hour later. No further activity. Are there any additional remediation steps we need to take other than patching the appliances such as rotating internal certificates, etc?

Is there anyway to tell if either of these are enabled or not configured on our locally managed spark gateways: 

Is there any data showing how long between exploitation and malicious activities started on internal networks?

[PhoneBoy · Accepted solution]

In the SK for CVE-2024-24919, which disclosed sensitive information stored on the gateway that could be used for lateral movement and compromise of internal networks, we provide a number of recommended steps.
In the case of CVE-2026-50751, the only thing "disclosed" is your encryption domain, DNS server, and possibly your DHCP server (if you're using that to assign Office Mode IPs).

As for applying mitigations, the CVE is only relevant when all of the following are true:

1. VPN Remote Access or Mobile Access is enabled
2. IKEv1 is enabled for remote access
3. Gateways accept legacy Remote Access clients
4. Gateways do not demand a machine certificate for connections

Provided you have disabled IKEv1 per sk185033, then you have successfully mitigated the issue (i.e. the other options aren't needed).
In any case, the other mitigation options are not available on locally managed SMB appliances.

Once you remediate, you should follow your Incident Response plan to ensure no other resources were accessed or compromised.
Check Point does offer Incident Response services that can assist with this. 

[Romaryo]

HI @PhoneBoy Have I understood correctly that we do not need to install the hotfix if one of the three mitigation options has been implemented?

We have already implemented Option 1 and will implement Option 3 shortly. Option 2 is not applicable in our environment because we are using R81.20 with Standalone Clients. As far as I understand, IKEv2 is only supported starting with R82.

In addition, we installed the hotfix for Take 141. Since then, we have been experiencing issues: VPN connections are disconnected after approximately one hour, and users are then unable to establish a new connection.

When we uninstall the hotfix, everything works normally again without any issues.

best regards,

Roman

[sx8n20394]

@PhoneBoy We are having the same issue Quantum Spark R82.00.10 Latest Build 2216. This needs to be investigated by R&D and hopefully fixed quick.

Edit: What we are seeing is clients who use Entra SSO for remote access will be asked to login again. The browser will randomly pop open and prompt for M365 login. This is normal behavior on initial connect but we have never had this happen during an active session. 

[VytasM]

Same issue with 1 hour disconnects after applying Hotfix firmware to locally managed 2570 and using RemoteAccess VPN E89.11, E89.20. We attempted to eliminate use of IKEv1 per sk166415, on device changed 'prefer IKEv2 but allow IKEv1', on clients applied registry change disable_ikev2=0 - that leads to failure to renegotiate after 1 hour and errors such as 'Informational exchange: Sending notification to peer: Invalid IKE SPI.(+) IKE SPIs', 'decryption failure:="Unknown SPI: 0x77e8be85 for UDP encapsulated IPsec packet'....

[sx8n20394]

Open a TAC case. We have one open but the more opened, the faster they will probably be on this issue. Did IKEv1 drop for you though? We haven't had a chance to test with IKEv1 to see if it drops.

[VytasM]

IKEv1 has no issues, VPN connection from clients left at default registry keys are stable as with prior R82.00.10 Build 998002203. It's not critical for us to stop using IKEv1 ASAP. Figured Checkpoint team is quite busy as it is and this issue will be noticed and corrected in next build. We did not test IKEv2 with prior firmware version.

[sx8n20394]

Did you notice if it still disconnected when disable_ikev2 = 0 reg key was set but firewall was on IKEv1?

[VytasM]

We have performed the test - yes VPN is stable (no disconnects) with Firewall set to IKEv1 and VPN client set at disable_ikev2 = 0,(PC rebooted after registry change).

[sx8n20394]

Thanks. I was able to test this last night and was successful no matter the auth method.

[PhoneBoy]

In terms of mitigating the CVE, implementing one of the three options is sufficient.
We still officially recommended installing the JHF due to other security hardening that was done.
Having said that, if it's causing an issue, I understand uninstallng it. 

[David_C1]

I have a question on the conditions listed:

As for applying mitigations, the CVE is only relevant when all of the following are true:

1. VPN Remote Access or Mobile Access is enabled
2. IKEv1 is enabled for remote access
3. Gateways accept legacy Remote Access clients
4. Gateways do not demand a machine certificate for connections

My scenario:

None of our gateways have Mobile Access blade enabled.

Some of our gateways have IPSecVPN blade enabled - this is only used for S2S VPN. None of our gateways are a member of the "RemoteAccess" VPN community.

Am I in the clear for CVE-2026-50751? (I understand CVE-2026-50572 is another issue, we are not impacted by this vulnerability).

Dave

[PhoneBoy]

The CVE is specific to Remote Access functionality, which can either use VPN blade or Mobile Access.
If you're using neither (i.e. just Site-to-Site), this CVE is not relevant.

[David_C1]

That makes sense - even though I have IPSec VPN Blade enabled (which I assume is what you are calling "VPN blade") because I don't have any gateway in Remote Access VPN community and not VPN Clients allowed, etc. we are not vulnerable. There's just a little lack of clarity on what is required for "VPN Remote Access" to be considered as enabled.

Dave