The VPN flaw that skipped the login screen

The Verizon DBIR's 2026 edition puts exploitation of publicly exposed software ahead of every other initial-access vector, and CVE-2026-50751 is a clean example of why. A CVSS 9.3 authentication bypass in Check Point Remote Access VPN, Mobile Access and Spark Firewalls let unauthenticated attackers establish a VPN session with no credential, no certificate and no private key. Check Point patched it on 8 June 2026; in-the-wild exploitation traces back to early May, and at least one victim went on to a Qilin ransomware affiliate. A working proof-of-concept client was published four days after the patch.

Description of the vulnerability

The bug lives in the IKEv1 Phase 1 handshake — the legacy key-exchange protocol still enabled on many Remote Access deployments for backwards compatibility.

During negotiation, a connecting client can supply a crafted Vendor ID payload that manipulates the gateway's internal authentication flags. Combined with improper certificate validation in that same handshake, the gateway concludes the peer has authenticated when nothing of the sort happened. The attacker is then issued a session as a provisioned Remote Access user.

Two properties make this worse than a typical edge-device CVE:

• There is no credential event to detect. No failed logins, no MFA prompt, no password spray pattern. Detection depends on noticing a session that should not exist, which is a much harder signal to alert on.
• The landing spot is inside. A web application flaw gives an attacker one application. A VPN bypass gives them the network segment the VPN was built to reach — which is precisely why ransomware crews prioritise this class of bug.

Hotfixes exist for R81.10.X, R81.20, R82, R82.00.X and R82.10. Four affected branches — R80.20.X, R80.40, R81 and R81.10 — are End of Support and will never receive a fix.

Resolution steps

1. Identify every Check Point gateway you operate, including the branch-office Spark appliances. These devices are frequently owned by networking rather than security, and are the most commonly missed items in a patch sweep.
2. Apply the vendor hotfix for your branch immediately if it is supported.
3. If you are on an End-of-Support branch, treat it as an upgrade emergency. There is no patch coming. Plan the migration and apply the compensating controls below in the meantime — indefinitely running an unpatchable internet-facing device with a public PoC against it is not a maintenance decision, it is an accepted breach.
4. Disable legacy IKEv1 and legacy Remote Access client support where the business can tolerate it. IKEv2 is not affected by this flaw, and IKEv1 has been deprecated for years.
5. Enforce mandatory machine-certificate authentication for Remote Access, which raises the bar for anyone who reaches the gateway.
6. Hunt back to early May 2026 on any gateway that was exposed and unpatched: VPN sessions for accounts that were not in use, connections from unfamiliar geographies or ASNs, and lateral movement from VPN-assigned IP ranges shortly after a session started.
7. Rotate credentials for accounts that were reachable through the VPN if you find anything — bypassed authentication means the account list itself was exposed to abuse.

Conclusion

Edge devices — VPN concentrators, firewalls, remote-management gateways, identity platforms — dominate the KEV catalogue in 2026 for a structural reason: they are internet-facing by design, they are patched on a slower cadence than web applications, and compromising one lands the attacker inside rather than beside your network. Anything answering on your perimeter needs the same inventory discipline and the same patch clock as your production web tier.

CyberSpec scans your perimeter on a schedule and flags exposed services against known-exploited vulnerabilities, so an End-of-Support appliance shows up on a findings page rather than in an incident report.