Imagine a VPN gateway that asks the connecting client “are you authenticated?” and then accepts whatever answer comes back. No verification, no cross-check, just take the client at its word. That is CVE-2026-50751, and the researchers at watchTowr Labs who discovered it captured the absurdity in three words: marking your own homework.
CVE-2026-50751 is a CVSS 9.3 authentication bypass in Check Point’s Remote Access VPN — the centrepiece of the broader Check Point VPN zero-day incident — actively exploited by a Qilin ransomware affiliate across the 32 days before Check Point’s advisory. CISA added it to the Known Exploited Vulnerabilities catalogue the same day. The flaw lives in the iked daemon’s handling of IKEv1, a protocol deprecated since 2005, and exploits a logic path where client-supplied flags directly control whether the gateway bothers checking a certificate at all.
The vulnerability is a design decision that delegated authentication enforcement to the party being authenticated. No cryptographic break was required, just a code path that asked the client “should I verify your identity?” and honoured the answer.
How Does the “Marking Your Own Homework” Bypass Actually Work?
The bypass operates during the IKEv1 Main Mode handshake, the six-message exchange that sets up an encrypted tunnel. Messages 1 through 4 handle Diffie-Hellman parameter negotiation. Messages 5 and 6 carry the encrypted identity payload and the authentication material: the certificate and its signature. Normally the gateway verifies both. Here, it does not.
The attacker injects a Vendor ID payload containing the 16-byte sequence 3c f1 87 b2 47 40 29 ea 46 ac 7f d0 ea f2 89 f5, the VPNExtFeatures identifier that Check Point’s iked daemon recognises. When processVendorIDPayload() sees those bytes, it reads the four trailing bytes, byte-swaps them, and writes them directly into the phase-1 negotiation state at memory offset state + 0x4bc4. The client’s raw bytes land in a memory location that controls authentication gating. No validation, no sanity check.
Two bits in that dword matter. Bit 0x2 gates whether the signature verification step runs. Bit 0x4 gates whether the full phase-1 signature check fires. Set both bits, and the gateway short-circuits past every authentication gate. In verify_peer_auth, if bit 0x4 of state[0x4bc4] is set, the function returns “authenticated” without ever calling verifyMessagePhase1.
The attacker then presents a self-signed X.509 certificate minted moments earlier, a 256-byte signature of random bytes, and a username with the organisation’s ICA string. The Diffie-Hellman exchange completes normally. The gateway accepts the garbage certificate because every verification function has been told to skip work.
What does the attacker need to know beforehand? A valid username and the ICA organisation string. The username can be enumerated by probing the gateway: when you send an incorrect username, the gateway responds with a lookup failure and the handshake stalls early. When you send a valid one, the handshake proceeds to the authentication phase. The ICA string is visible in the gateway’s own TLS certificate, publicly served to anyone who connects. Neither barrier is cryptographic. As CelVexGroup put it, the gateway asks a question whose answer the connecting party gets to supply, and then trusts the answer.
The bypass works against Certificate, Certificate with Enrollment, and Mixed authentication methods. Legacy XAUTH with username and password is unaffected because the post-phase-1 password check still runs independently. And it works identically over TCP 443 via Visitor Mode as it does over UDP 500/4500, so perimeter UDP filtering provides no protection.
watchTowr Labs noted something telling: a gateway receiving only the VPNExtFeatures Vendor ID logs vendorid = 0 ... not a Check Point peer to its own logs, and then honours the “don’t check my signature” flag anyway. The gateway writes that it does not recognise you as a legitimate client, then lets you in regardless.
What Versions and Configurations Are Affected?
Now that you understand how the bypass works, the next question is whether your gateway carries this vulnerable code path.
Nine version branches are affected, spanning R80.20.X through R82.10. Four of those (R80.20.X, R80.40, R81, R81.10) have reached End of Support and receive no hotfix. If you are running one of those versions, migration to a supported release is your only remediation path.
Three conditions must all be true for exploitation: the gateway accepts legacy Remote Access clients, IKEv1 is enabled (not IKEv2-only), and machine certificate authentication is not set to mandatory. Gateways running IKEv2-only or enforcing mandatory machine certificates were functionally immune even without the patch, because the patched code reads server-side policy from state + 0x4bd4 before honouring any client-supplied flags.
The hotfix, sk185033, addresses CVE-2026-50751. A separate hotfix, sk185035, addresses the sibling vulnerability CVE-2026-50752. Organisations on R81.20 through R82.10 running both Remote Access and site-to-site VPN with IKEv1 need both.
Why Does IKEv1 Create This Vulnerability?
IKEv1 was standardised in RFC 2409 in 1998. IKEv2 superseded it in RFC 4306 in 2005. That is nearly two decades of deprecation, and the IETF has since initiated formal movement of IKEv1 to historic status. Yet Check Point continued shipping IKEv1 support for legacy client compatibility, and countless organisations kept it enabled because turning it off requires touching client configurations nobody wants to touch.
IKEv1’s protocol design left authentication enforcement to individual implementations. IKEv2 bakes certificate-based authentication into the protocol and does not expose a Vendor ID mechanism that can carry client-supplied authentication flags. The entire class of flaw exploited by CVE-2026-50751 has no equivalent attack surface in IKEv2.
This is not the first time a Check Point VPN zero-day has exploited a legacy protocol handler. CVE-2024-24919, the 2024 information disclosure vulnerability, was also exploited in the wild and added to CISA’s KEV catalogue. Two years apart, the same class of appliance, different deprecated code paths.
The same code-path review that produced the CVE-2026-50751 fix also uncovered a second vulnerability, CVE-2026-50752, which the next section examines in detail.
What Is the Relationship Between CVE-2026-50751 and CVE-2026-50752?
CVE-2026-50752 is a CVSS 7.4 man-in-the-middle vulnerability in the same IKEv1 certificate validation code path. Check Point’s BLAST agentic AI platform discovered it during the extended code review triggered by the CVE-2026-50751 investigation.
The two vulnerabilities share the same location in the iked daemon but are different vulnerability classes. CVE-2026-50751 is an authentication bypass (CWE-287) that lets an attacker skip certificate validation entirely. CVE-2026-50752 enables a MITM attack against site-to-site VPN connections when specific conditions are met. It affects a narrower version range (R81.20 through R82.10) and has no observed in-the-wild exploitation.
The discovery sequence is worth understanding. Active exploitation was detected on 4 June, which triggered a vendor investigation. Rather than surgically fixing the single identified flaw, Check Point’s BLAST platform conducted a thorough review of the entire IKEv1 certificate validation code path. That review surfaced CVE-2026-50752, a vulnerability that a targeted patch for CVE-2026-50751 alone would have left behind.
Two separate hotfixes address the two CVEs: sk185033 for CVE-2026-50751 and sk185035 for CVE-2026-50752. Organisations with overlapping affected versions running both Remote Access and site-to-site VPN with IKEv1 need both.
How Did Qilin Affiliates Exploit It in the Wild?
Check Point detected suspicious VPN activity on 4 June 2026 and traced initial exploitation to on or around 7 May, a 32-day window — detailed in the full exploitation timeline — during which the bypass was actively used without public knowledge of the vulnerability. At least one confirmed post-compromise incident was attributed with medium confidence to a Qilin ransomware affiliate, based on ELF payloads that matched known Qilin Linux ransomware samples and consistent post-access tradecraft.
The campaign was a targeted operation focused on a few dozen organisations globally. Attacker infrastructure was distributed across multiple hosting providers with geographic correlation to victims, suggesting deliberate targeting rather than opportunistic scanning. In some cases, VPS infrastructure geolocated to Taiwan targeted Taiwanese organisations.
Post-exploitation behaviour followed a familiar ransomware playbook: ELF payload deployment, Rclone-based data staging and exfiltration, and Tox protocol C2. The kill chain itself is short: find an exposed gateway, bypass authentication, land an internal-facing VPN session, and pivot. As CelVexGroup noted, the dangerous property is that the first two steps require no credential and no user interaction. For a full account of how Qilin affiliates operationalised the bypass inside compromised networks, the post-exploitation chain reveals a disciplined ransomware operation that compressed the time from initial access to deployment.
How Can Organisations Detect Whether Their Gateway Was Compromised?
With exploitation predating disclosure by a month, forensic log review is the difference between patching a vulnerability and discovering you are already inside an active incident.
The primary detection surface is VPN session logs from 7 May onward. Certificate-based authentication sessions with no corresponding valid certificate authority chain, or where the authentication event in SmartConsole is missing entirely, are the signals to hunt. A vulnerable gateway logs vendorid=0 ... not a Check Point peer when receiving only the VPNExtFeatures Vendor ID. Correlate that log entry with a successful phase-1 SA creation and you have a direct compromise indicator.
Rapid7’s MDR rules for InsightIDR operationalise the hunt by looking for IKEv1 negotiation events from known attacker infrastructure, anomalous Distinguished Name patterns in certificate subjects, and IKE phase-1 sessions that completed without the expected signature verification log entries. Post-exploitation signals worth hunting include Rclone outbound connections from VPN-assigned IPs, unusual ELF binary execution on gateway-adjacent hosts, and Tox protocol communication on non-standard ports.
watchTowr Labs published a Detection Artefact Generator on GitHub for defenders. It reproduces the IKEv1 negotiation patterns attackers used, without weaponisation, so you can validate that your logging infrastructure captures the relevant events before you need them.
CVE-2026-50751 exposed a vulnerability class that sits deeper than a single hotfix can reach. The investigation it triggered uncovered CVE-2026-50752 in the same deprecated IKEv1 code path, found only because Check Point’s BLAST platform conducted a thorough review rather than a targeted fix. One hotfix closes the authentication bypass. A second hotfix closes the MITM vector. Retiring IKEv1 eliminates the entire attack surface and all future vulnerability classes it might harbour.
Patching addresses the immediate risk. Retiring deprecated protocol stacks removes the attack surface entirely. The recurrence pattern across CVE-2024-24919 in 2024 and both 2026 CVEs suggests edge appliances running legacy protocol handlers will remain recurring targets. The operational response has two phases: apply the hotfixes and hunt for compromise indicators now, then ask which other deprecated protocols are still enabled on your edge appliances, and whether patching alone is enough when VPN appliances are systematically targeted — a question at the heart of what this means for VPN defence strategy.
Frequently Asked Questions
Is disabling IKEv1 enough, or do I still need the hotfix?
Disabling IKEv1 protects you from CVE-2026-50751 and CVE-2026-50752 immediately because the vulnerable code path inside the iked daemon simply never activates. However, you should still apply hotfix sk185033. Check Point’s advisory confirms that IKEv1-only customers must patch their gateway, and leaving a known-vulnerable code path present on your appliance is a risk management failure even when it is not actively serving traffic.
What if I can’t patch immediately — are there temporary mitigations?
Yes. Enforce mandatory machine certificate authentication. This forces the gateway to check server-side policy at state + 0x4bd4 before processing any client-supplied Vendor ID flags, and the is_machine_cert_supported() function overrides the attacker-controlled bits. Alternatively, disable IKEv1 entirely and switch to IKEv2-only Remote Access. Both mitigations neutralise the attack surface without applying the hotfix, though patching remains the only complete remediation.
Can the attacker see my network traffic after bypassing authentication?
No. The Diffie-Hellman key exchange completes normally and produces an encrypted tunnel regardless of whether authentication is bypassed. The attacker cannot passively decrypt existing traffic or inject packets into authenticated sessions belonging to other users. What the bypass grants is an authenticated VPN session under the attacker’s control, which provides internal network access. The confidentiality of legitimate traffic is not compromised by the authentication flaw itself.
Is XAUTH or username/password authentication safe from this vulnerability?
Yes. Legacy mode with XAUTH requires a valid username and password after phase-1 negotiation completes, and CVE-2026-50751 only disables certificate validation during the IKE main mode handshake. The attacker still faces a functioning password check in XAUTH and cannot proceed without valid credentials. However, certificate-based methods (Certificate, Certificate with Enrollment, and Mixed) have no equivalent post-phase-1 gate, which is why they are the exploitable configurations.
How do I check whether my gateway is using IKEv1 or IKEv2?
In SmartConsole, navigate to the Remote Access VPN community properties and examine the Authentication tab. The IKE version is displayed under the Phase-1 negotiation settings. IKEv1-only gateways list IKEv1 with no IKEv2 fallback. You can also verify via CLI on the Security Gateway itself by reviewing the $FWDIR/conf/vpn.conf file for the ike_use_ikev2_only directive. CelVexGroup’s passive exposure methodology provides a non-weaponised external validation method.
How does CVE-2026-50751 compare to the 2024 Check Point VPN zero-day?
CVE-2024-24919 was an information disclosure vulnerability that leaked sensitive files from the gateway, including password hashes and private keys. CVE-2026-50751 is an authentication bypass that skips certificate validation entirely. Both achieved VPN access without valid credentials, both were exploited in the wild before disclosure, and both were added to CISA’s Known Exploited Vulnerabilities catalogue. The 2026 flaw is the more severe of the two, earning a CVSS 9.3 versus 8.6.
Does two-factor or multi-factor authentication protect against this bypass?
No. The authentication bypass fires during IKE phase-1 certificate validation, which occurs before any second-factor challenge is presented. Multi-factor authentication typically operates at the application layer after the VPN tunnel is established, meaning the attacker already has an authenticated session before MFA would be invoked. Certificate-based configurations with MFA layered on top remain exploitable because the bypass defeats the gatekeeper that sits in front of the second-factor prompt.
Will applying the hotfix break existing VPN connections?
No. Hotfix sk185033 patches the processVendorIDPayload() handler inside the iked daemon to read authentication policy from the server-side configuration at state + 0x4bd4 rather than trusting client-supplied flags. The IKE negotiation protocol, encryption parameters, and existing tunnel configurations remain unchanged. Remote Access VPN users connecting with valid certificates or XAUTH credentials will experience no disruption. Check Point recommends a maintenance window as standard practice for any gateway hotfix deployment.
Do I need to apply both sk185033 and sk185035?
Only if your gateway falls within the overlapping affected version range and you run both Remote Access VPN and site-to-site VPN with IKEv1. sk185033 addresses CVE-2026-50751, the authentication bypass, while sk185035 addresses CVE-2026-50752, the man-in-the-middle vulnerability. Gateways running R81.20 through R82.10 with site-to-site VPN enabled need both hotfixes. Organisations on R80.20.X through R81.10 are only affected by CVE-2026-50751 and require only sk185033.
Is Check Point the only VPN vendor with this type of IKEv1 vulnerability?
No vendor is inherently immune to IKEv1 authentication flaws, because the protocol delegates authentication enforcement to individual implementations. Check Point’s specific vulnerability arose from a logic error in how iked processed Vendor ID payloads, but any vendor that ships an IKEv1 implementation with client-side authentication flag handling could harbour similar bugs. The structural risk is the deprecated protocol itself, which is why the IETF is moving IKEv1 to historic status and why retiring it matters beyond any single CVE.
