By A Qilin ransomware affiliate has been walking through Check Point VPNs since May 7 — not by cracking encryption or finding a clever new attack surface, but by flipping an authentication flag that the gateway lets clients set themselves. The patch arrived June 8. That’s 32 days of uninterrupted access across organizations that thought their VPN was doing its job.
If you’re running Check Point Remote Access VPN or Mobile Access with IKEv1 enabled, you may still be exposed. Here’s what happened, what’s affected, and what you need to do today.
What Happened
CVE-2026-50751 is a critical authentication bypass (CVSS 9.3) in Check Point’s Remote Access VPN and Mobile Access components — specifically deployments still using the deprecated IKEv1 key exchange protocol. A Qilin ransomware affiliate discovered it first. Check Point didn’t detect the malicious activity internally until June 4, three-plus weeks into the campaign.
On June 8, Check Point released hotfixes and disclosed publicly. CISA added CVE-2026-50751 to its Known Exploited Vulnerabilities (KEV) catalog the same day and gave federal agencies three days to patch. “A few dozen” organizations were hit — Check Point’s language, which traditionally means the real number is higher.
The Technical Flaw
Watchtowr Labs described this as “marking your own homework,” and that framing is exactly right. During IKEv1 key exchange, Check Point gateways read four trailing bytes from the client-supplied VPNExtFeatures Vendor ID payload and write them directly into an authentication flag register — with no server-side validation. The client tells the gateway how strict to be about verifying the client. Setting bit 0x4 disables signature verification. Setting bit 0x2 skips certificate processing entirely. An unauthenticated attacker can establish a full VPN session by simply instructing the server not to verify them.
This isn’t a subtle race condition or a heap overflow requiring precise timing. It’s a design flaw in how the server trusts client-supplied control data — a category of mistake that should have been caught 20 years ago when IKEv1 was still the current protocol.
Are You Affected?
You’re exposed if all four conditions are true:
- Remote Access VPN or Mobile Access is enabled on your Check Point gateway
- IKEv1 is configured (often left on as a legacy compatibility fallback)
- Support for legacy Remote Access clients is enabled
- Machine Certificate Authentication is not required for all connections
Vulnerable versions by Jumbo Hotfix Take:
- R82.10: Jumbo Hotfix Take 19 or below
- R82: Jumbo Hotfix Take 103 or below
- R81.20: Jumbo Hotfix Take 141 or below
- R81, R81.10, R80.40: End-of-support — no patch exists. Upgrade required.
A companion vulnerability, CVE-2026-50752 (CVSS 7.4), affects the same IKEv1 certificate validation code and allows man-in-the-middle attacks on site-to-site VPN connections. No observed exploitation yet — but the same Jumbo Hotfixes cover both. Patch it too.
What to Do Right Now
If you’re on a supported version, apply the Jumbo Hotfix immediately per the official Check Point advisory (sk185033):
- R82.10: Upgrade to Jumbo Hotfix Take 20 or later
- R82: Upgrade to Jumbo Hotfix Take 104 or later
- R81.20: Upgrade to Jumbo Hotfix Take 142 or later
If you can’t patch immediately, apply these mitigations first:
- Disable legacy Remote Access client support in Gateway Settings
- In SmartConsole: Global Properties → Remote Access VPN Authentication → set to IKEv2 Only
- Require Machine Certificate Authentication for all connections
- Enable IPS and pull the latest signatures
Then review IKEv1 authentication logs from May 7 onward. Sessions establishing without valid machine certificates are suspect. Per Rapid7’s threat analysis, watch for unexpected ELF binary downloads or Rclone execution on internal hosts shortly after VPN authentication events — both are indicators of post-compromise Qilin activity.
The Broader Problem
IKEv1 was deprecated in 2005 — RFC 4306 replaced it with IKEv2. That was 21 years ago. Yet it remains enabled by default in production Check Point gateways as a “compatibility” option, and that option just became Qilin’s entry point into several dozen corporate networks.
This isn’t unique to Check Point. The same threat actor infrastructure is actively exploiting VPN authentication flaws in Palo Alto, Fortinet, and F5 products simultaneously. The pattern is consistent: vendors keep legacy protocol support enabled by default, organizations don’t audit it because it’s “not broken,” and ransomware groups quietly catalog the exposure.
Deprecated protocol support isn’t a compatibility feature. It’s a liability that doesn’t appear in your risk register until a ransomware affiliate finds it first. Patch today. Then audit every gateway for legacy protocol fallbacks you didn’t know were on.
