Check Point patches IKEv1 VPN bypass CVE-2026-50751, exploited since May

Check Point published an emergency advisory on June 8, 2026 for CVE-2026-50751 — an authentication-bypass flaw in Remote Access VPN and Mobile Access deployments still negotiating the deprecated IKEv1 key exchange. CVSS v3.1 is 9.3 (Critical). The vendor confirms active exploitation in the wild since at least May 7, 2026, with one case assessed at medium confidence as a Qilin ransomware affiliate. Hotfixes are out under SK185033; rollout is required on emergency change without waiting for the next maintenance window.

What the bug does

The flaw is a logic error in certificate validation during IKEv1 negotiation. On gateways that accept legacy Remote Access clients without requiring a machine certificate, an attacker who can reach the IKE service over the network can complete authentication and open a VPN session without holding a valid user password. From there the attacker rides whatever per-user posture and routing the gateway grants — typically full access to internal network segments, sufficient to pivot to AD, file shares, or whatever the user the spoofed identity is provisioned for can reach.

CWE-287 (Improper Authentication). It is not a memory-corruption bug, not unauthenticated RCE on the appliance itself — but in operational terms the impact is equivalent for the network behind the gateway.

Affected products

Per Check Point's own enumeration in the advisory:

• Remote Access VPN clients (Mobile Access / SSL VPN gateways).
• Mobile Access blade on supported Security Gateways.
• Spark Firewall product line.

Affected version trains span R80.20.X through R82.10. The trigger is configuration-dependent — only deployments that accept IKEv1 and do not enforce machine certificates on legacy clients are exploitable. Gateways already enforcing IKEv2-only, or requiring machine certs for IKEv1 connections, are not in the exposed population per the advisory.

Exploitation status

Check Point Research's own June 8 write-up is the primary attribution surface. The timeline as the vendor states it:

• May 7, 2026 — earliest observed exploitation telemetry.
• Early June 2026 — escalation in attempt volume.
• June 4, 2026 — Check Point opens its investigation.
• June 8, 2026 — hotfixes and advisory published.

Independent coverage at The Hacker News, Help Net Security, Rapid7's ETR, and Dark Reading repeats the same Check Point-sourced framing: limited targeting (a few dozen organisations globally so far), at least one Qilin-affiliated post-compromise case. Attribution beyond the Qilin link is hedged in the advisory; treat anything more specific as commentary until Check Point publishes further.

runZero's discovery guidance lists fingerprinting queries to identify Check Point gateways across your own estate — useful for the inventory step below.

Action checklist

1. Apply the hotfixes from SK185033 to every Remote Access and Mobile Access gateway in the R80.20.X through R82.10 range. This is the emergency-change patch; do not queue it for next month's window.
2. Disable IKEv1 entirely where business continuity allows. Enforce IKEv2-only on the VPN gateway. The protocol is deprecated for a reason — every gateway that still accepts it is one configuration drift away from this exact failure mode regardless of which CVE is current.
3. If IKEv1 must remain enabled for a legacy client population, require machine certificates for IKEv1 connections at the gateway. Check Point's own guidance confirms gateways enforcing machine cert auth on IKEv1 are out of the exploitable population.
4. Inventory your Check Point footprint. Pull every appliance running R80.20.X through R82.10 from your CMDB. If you are not sure what is reachable, use the runZero discovery queries linked above against your perimeter and any third-party-managed networks you depend on.
5. Hunt for post-compromise activity on every gateway that has accepted IKEv1 connections from external sources since May 7. Pull VPN session logs, correlate with downstream AD authentication events for the impersonated identities, and look for unexpected lateral movement off the per-user network segment. A Qilin affiliate had at least a month of operating room before the patch shipped.
6. Rotate credentials for any user whose VPN session originated from an unrecognised source IP during the exposed window. Bypass auth on the VPN ≠ bypass auth on AD, but session reuse and stolen post-auth tokens are the next pivot.

Context

Check Point's last comparable IKE-stack disaster was CVE-2024-24919 in May 2024 — an unauthenticated information disclosure in the same Remote Access / Mobile Access surface, mass-exploited within days of disclosure. CVE-2026-50751 is the third year running that the same product line has shipped a perimeter-edge authentication or disclosure flaw exploitable from an unauthenticated network position. The pattern across the broader VPN-appliance category — Ivanti, Fortinet, Palo Alto, SonicWall, Check Point — is now too consistent to call coincidence: the protocol surface these boxes accept is wider than their development pipelines can audit at the pace ransomware operators need.

If you operate IKEv1 on any vendor's gateway in 2026, the structural question is no longer "when will we get to the IKEv2 migration." It is what other audit failures of the same shape are sitting in the same code paths, on the same appliances, behind the same patch-Tuesday lag. Treat every internet-reachable VPN concentrator as a Tier-0 asset whose patch SLO is measured in hours, not weeks. The Qilin operator had a month here — the next operator will not need that long.