A critical authentication bypass in Check Point Remote Access VPN has been actively exploited since at least 7 May 2026 — more than a month before the vendor patched it. The flaw, CVE-2026-50751 (CVSS 9.3), lets an unauthenticated attacker establish a full VPN session without ever supplying valid credentials, and one confirmed post-compromise chain ended in a Qilin ransomware deployment.
How the Bypass Works
The root cause sits in how Check Point gateways process the VPNExtFeatures Vendor ID payload during IKEv1 key exchange. As watchTowr Labs discovered, the gateway reads four trailing bytes from this client-supplied payload and writes them directly into an authentication flag register at offset 0x4bc4. The client can set bit 0x4 to disable signature verification or bit 0x2 to skip certificate processing entirely.
The result: a connecting client tells the server how thoroughly to check its identity, and the server complies. No valid private key is needed — a self-signed certificate or random garbage signature works. All the attacker requires is a valid username and the ICA organisation string, both of which are readable from the gateway’s publicly exposed TLS certificate.
The attack reaches gateways over UDP 500/4500 and TCP 443 (Visitor Mode/TCPT), meaning internet-exposed deployments with legacy client support enabled are directly reachable. A second related vulnerability, CVE-2026-50752 (CVSS 7.4), affects IKEv1 certificate validation in site-to-site tunnels and could allow man-in-the-middle interference, though no in-the-wild exploitation has been observed for that one.
Affected Versions
According to Check Point’s advisory and Rapid7’s ETR, all of the following are affected:
- R80.20.X (End of Support)
- R80.40 (End of Support)
- R81, R81.10, R81.10.X (End of Support)
- R81.20
- R82, R82.00.X, R82.10
End-of-support versions receive no hotfix. Organisations on those releases must migrate or accept residual risk with the workarounds below.
Exploitation Timeline and Threat Actor
BleepingComputer reported and Check Point confirmed that exploitation started on 7 May 2026, with a surge in early June. Hotfixes were released on 8 June 2026 — 32 days after first observed compromise. The bug was added to CISA’s Known Exploited Vulnerabilities catalogue.
At time of Check Point’s disclosure, the company reported “a few dozen targeted organisations globally.” One confirmed incident involved a Qilin ransomware affiliate using dedicated VPS infrastructure hosted across Kaupo Cloud HK, Shock Hosting, and Vultr. Qilin, which surfaced in 2022 as an “Agenda” rebranding, has claimed approximately 400 victims on its dark-web leak site and has previously hit Yanfeng, Nissan, Synnovis, and Australia’s Court Services Victoria.
Detection and Patch Guidance
watchTowr Labs released a Detection Artefact Generator for testing whether a gateway accepts the malicious VendorID payload. Rapid7 published a vulnerability check in their June 9 content release and a detection rule (“Suspicious Authentication – Check Point VPN Authentication Bypass”) for InsightVM, Nexpose, and Exposure Command. Defenders should audit forensic logs from 7 May 2026 onward for unexpected IKEv1 sessions.
To remediate:
- Apply hotfixes from sk185033 immediately.
- If hotfixes cannot be applied at once, disable legacy remote access client support, enforce IKEv2-only authentication, and mandate machine certificate authentication.
- Enable IPS with the latest signatures.
- Begin migration away from end-of-support versions.
The patched firmware removes the vulnerable process_machine_certs parameter from process_cert_payloads() entirely — the client-controlled bitmask mechanism no longer exists in fixed builds.
Why This Pattern Keeps Appearing
CVE-2026-50751 follows a well-worn script: a legacy protocol that should have been disabled years ago, still accepted by default to support old clients, with a logic flaw that hands authentication control to the attacker. Check Point is not alone in this pattern — edge devices from multiple vendors have surfaced similar issues in recent years. The difference here is the explicitness of the flaw: the server was literally reading a client-provided byte and using it to skip its own certificate checks.
Any organisation with a Check Point gateway that still accepts IKEv1 should treat this as a fire drill: patch, then use the downtime to ask why IKEv1 is still permitted at all.