Check Point VPN: The Client Dictates Authentication (CVE-2026-50751)
One byte of the IKEv1 Vendor ID disables server-side verification. Exploited since May by a Qilin affiliate. Here are the IOCs, the Suricata rule, and the fix.
Some vulnerabilities stand out for their severity, others for the perverse elegance of their mechanism. CVE-2026-50751, rated CVSS 9.3, belongs to the second category. Documented by watchTowr Labs and Rapid7, it lets an unauthenticated attacker establish a full VPN session on a Check Point gateway without ever supplying a valid credential. The principle: the client itself tells the server how thoroughly to check its identity, and the server complies.
This flaw is not theoretical. It has been actively exploited since at least May 7, 2026, more than a month before the patch shipped, and it sits in CISA's Known Exploited Vulnerabilities catalog. One confirmed compromise chain ended in the deployment of Qilin ransomware. For any organization whose remote access relies on an IKEv1 Check Point gateway, the priority is immediate.
The mechanism: four bytes that disarm verification
The root cause lies in how Check Point gateways process the Vendor ID payload named VPNExtFeatures during the IKEv1 key exchange. The gateway reads four trailing bytes from this client-supplied payload and writes them directly into an authentication flag register, at a precise internal offset. The client can set bit 0x4 to disable signature verification, or bit 0x2 to skip certificate processing entirely. In other words, the client's packet carries a flag, here the value 0x00000004, that commands the server to lower its own guard.
This is an authentication bypass, tracked as T1190 (Exploit Public-Facing Application) followed by T1133 (External Remote Services). An important point for network detection: the bypass also works over TCP 443 when UDP access is blocked or filtered, which widens the exposure surface beyond the usual IKE port.
The published indicators of compromise
Researchers released several actionable indicators. On the gateway log side, the presence of the entry "not a Check Point peer" is a marker of the exploitation pattern. On the network side, nine source IP addresses were associated with the attacks:
45.77.149.152
209.182.225.136
38.60.157.139
162.33.177.101
45.76.26.42
144.208.127.155
38.54.88.201
38.54.107.167
66.42.99.200
Two MD5 hashes of associated payloads were also recorded: 52fda5c1b9704544f32ee98d9060e689 and 51d39aa39478beeac94f2d12f682ecce. A Qilin affiliate observed in one intrusion used dedicated VPS infrastructure to carry out the attack.
A Suricata rule on the malicious Vendor ID
The most robust network signature targets the VPNExtFeatures Vendor ID payload carrying the flag that disables verification. watchTowr Labs in fact released a Detection Artefact Generator to test whether a gateway accepts the malicious Vendor ID. Here is a Suricata rule that alerts on the exploitation pattern by watching IKE traffic:
alert udp any any -> $HOME_NET 500 (msg:"CheckPoint IKEv1 VPNExtFeatures auth bypass CVE-2026-50751"; \
content:"|00 00 00 04|"; \
flow:to_server; \
threshold:type limit, track by_src, count 1, seconds 60; \
reference:url,labs.watchtowr.com/marking-your-own-homework-check-point-remote-access-vpn-ikev1-authentication-bypass-cve-2026-50751/; \
classtype:attempted-admin; sid:2026050751; rev:1;)
This rule is a starting point to refine against your segmentation: the content match corresponds to the flag that disables verification. Complement it with a ruleset blocking the nine source IPs above, and with monitoring of port 443 on the affected gateways, since the bypass works there too.
The fix and the structural measure
Check Point published a fix under reference sk185033. Beyond the patch, the fundamental measure is to force IKEv2 and abandon IKEv1, the deprecated protocol at the root of the flaw. If your deployment allows it, disable IKEv1 on remote access gateways: this removes the entire vulnerability class, not just this instance. Finally, check the logs for the absence of sessions established from the listed IPs before the patch was applied, because a session opened via this bypass could have served as a beachhead.
Detecting and blocking active network exploitation requires up-to-date signatures and a stream of qualified indicators. That is what the ThreatClaw NIDS feed provides: Suricata rules built on the real exploitation mechanism, not just a list of ephemeral IPs, to cut access before the ransomware follows.
Related articles
A poorly validated override cookie opens an unauthorized GlobalProtect session. Score raised to 7.8, in the KEV, exploited. Nuclei detection and mitigation.
A NetScaler memory leak in SAML IdP mode replays the CitrixBleed scenario: token theft, MFA bypass, DragonForce. Here is WAF virtual patching.
From June to August 2026, ThreatClaw forged 72 new malware families into its YARA feed: Prometei, WannaCry, EternalBlue, GhostNFC, SpyNote, Mamont, Neshta… each tested against 5,694 legitimate binaries, zero false positives.
Deserialization of untrusted data yields RCE on on-premise SharePoint. In the KEV, exploited by Storm-2603. Here is the Sigma rule on w3wp and Nuclei detection.