The IKEv1 Bypass Is Client-Controlled. Check Point Logs the Login, Not the Vendor ID That Forged It

An unauthenticated attacker sends your Check Point gateway a vendor ID payload during IKE phase 1, and the gateway writes four attacker-supplied bytes straight into the flag word that governs whether it bothers to check the client’s certificate. Set the right bit and the signature-verification routine never runs. The gateway returns “authenticated” and builds the tunnel. That is CVE-2026-50751, and the reason it matters to whoever owns detection engineering is not the elegance of the bug. It’s that the thing you would most want to alert on — the forged vendor ID payload — isn’t in the logs your SIEM receives, and never was.

Check Point published the advisory and hotfixes on June 8, 2026, and CISA added it to KEV the same day, with a June 11 remediation due date for covered federal systems. Per Rapid7’s incident writeup, the earliest confirmed exploitation predates the advisory by a month, back to May 7 — and Check Point has, with medium confidence, tied at least one of those intrusions to an affiliate of the Qilin ransomware-as-a-service operation. Which means anyone running an affected branch had a four-week window where the only record of compromise is whatever their VPN logs happened to retain. Worth being precise about what the bypass buys the attacker: a live tunnel, not automatic domain compromise. Reaching internal systems or escalating still takes post-authentication activity — but a ransomware affiliate has every reason to do that work, which is exactly why the log-review window is worth the effort to reconstruct. If your remote-access gateway logs age out at 30 days in the hot tier, do the arithmetic before you assume you can go look.

What the flag actually does

The mechanism, as reconstructed by watchTowr Labs, is a logic flaw in IKEv1 phase-1 certificate validation. The client sends a VPNExtFeatures vendor ID payload — Check Point’s own extension, magic bytes 3c f1 87 b2 47 40 29 ea 46 ac 7f d0 ea f2 89 f5 — and the four bytes immediately following that 16-byte magic get byte-swapped and written directly into a flags word at offset 0x4bc4 in the negotiation state. If bit 0x4 lands set, the boolean short-circuit in the auth path returns success before the verification function is ever called. The gateway believes it validated a certificate it never looked at.

That covers three of the four SSL Network Extender user-authentication modes: certificate, certificate-with-enrollment, and mixed. The fourth, legacy username/password, isn’t bypassable the same way — XAUTH still gates it on a password afterward. For the three certificate modes, though, the client is choosing, from outside, whether the server enforces its own auth policy. This is the same class of failure as any “trust the client’s assertion about how much to trust the client” bug, and it’s why the affected version spread is so wide — R80.20.x through R82.10, across Remote Access VPN, Mobile Access / SSL VPN, and the Quantum Spark firewall line. Nine branches, some already end-of-support, which is its own problem.

The same hotfix also closes a quieter sibling. CVE-2026-50752 is an improper-certificate-validation flaw (CVSS 7.4) in the same deprecated IKEv1 code path, but it’s a different animal: it lets an attacker already sitting between two VPN peers present a certificate the responder wrongly accepts, tampering with a certificate-authenticated site-to-site tunnel. It needs that privileged network position, it hasn’t been seen exploited in the wild, and it rides along on the exact fix you’re already deploying for 50751 — so it’s a footnote for completeness, not a second fire.

Two things do not save you but often get cited as if they do. Pre-shared key setups aren’t in scope the same way, and a pure IKEv2 posture sidesteps the phase-1 path entirely. That second point is the actual remediation lever, and I’ll come back to it.

The payload isn’t in your security logs

Here’s where most teams start on the wrong foot. The instinct is to write a detection for the vendor ID — grep for the magic bytes, alert on the malformed VPNExtFeatures payload. You can’t, at least not from the logs your SIEM actually receives. Vendor ID payloads are IKE phase-1 negotiation internals, and Check Point does not export them through Log Exporter. You only see them if you are deliberately collecting packet-level IKE data, IKE debug, or equivalent gateway diagnostics — none of which is a normal steady-state feed. The structured logs that land in your cp_log sourcetype in Splunk (or the Elastic equivalent, which is messier because the Check Point field mapping never quite survives the ingest pipeline intact) carry the outcome of the negotiation, not the wire-level payloads that produced it.

The place those payloads exist is IKE debug — vpn debug ikeon, the $FWDIR/log/ike.elg files you’d crack open in IKEView. That is not running in production. Under real remote-access load, .elg retention can be very short unless the files are explicitly sized, collected, and protected, and nobody is shipping .elg to a SIEM as a matter of course. So if your detection strategy depends on seeing the forged vendor ID, the strategy is a lab artifact. It works in your test bench where you turned IKE debug on to reproduce the bug, and it evaporates the moment you push it to a gateway carrying two thousand road-warrior sessions.

There is one wire-level tell worth knowing about, even though you probably can’t act on it directly: watchTowr noted the gateway logging vendorid=0 ... not a Check Point peer while simultaneously completing authentication for that same peer. A rejection message and a successful auth for one negotiation. If any part of your pipeline captures IKE-level diagnostic strings — some shops forward the vpnd debug channel to syslog during active IR, not routinely — that inconsistency is a high-fidelity signal. For steady-state detection, assume it isn’t there.

One more thing not to assume at the network layer: that UDP/500 and UDP/4500 visibility covers the attack surface. watchTowr demonstrated the same bypass over Check Point’s Visitor Mode, which tunnels IKE inside TCP/443. A packet-level or firewall rule scoped to the classic IKE ports misses that path entirely, so if you’re leaning on any network-side signal at all, it has to include the TCP/443 Visitor Mode transport.

Detect the session, not the exploit

Since the exploit is invisible, you alert on the thing it produces: a remote-access session that authenticated under conditions your policy says shouldn’t authenticate.

The field to anchor on is the authentication scheme recorded on the login event. Check Point’s remote-access login logs carry a scheme/method value — the exact field name depends on your Log Exporter version and whether you’re on the Check Point Splunk app or raw syslog, but you’re looking for the record that says this session came up via IKEv1 certificate auth. In a shop that has standardized on IKEv2 with machine certificates, any successful IKEv1 certificate session is anomalous by definition. That’s your first and best rule, and it’s nearly free:

index=vpn sourcetype=cp_log
(action=login OR action=accept OR eventtype=vpn*)
| search vpn_protocol="IKEv1" OR ike_version="IKEv1" OR key_exchange="IKEv1"
| search auth_method="*Certificate*" OR login_option="*Certificate*" OR authentication_method="*Certificate*"
| stats count min(_time) as first_seen max(_time) as last_seen by user src origin auth_method login_option

Field names there are illustrative — verify them against your own ingested events before you trust the query, because Check Point’s Log Exporter has renamed VPN fields more than once between major releases and the app’s CIM mapping lags. The redundant OR-ed field names are deliberate: they hedge across Log Exporter versions rather than betting on one schema. Pair it with a companion hunt for the sessions where the method field came back empty rather than certificate — the ambiguous cases you don’t want to silently drop:

index=vpn sourcetype=cp_log
(action=login OR action=accept OR eventtype=vpn*)
| search vpn_protocol="IKEv1" OR ike_version="IKEv1" OR key_exchange="IKEv1"
| where isnull(auth_method) OR auth_method="" OR auth_method="unknown"
| stats count min(_time) as first_seen max(_time) as last_seen by user src origin auth_method login_option The point is the logic: successful certificate-scheme login on the legacy key exchange, on a gateway where that combination should be extinct.

Volume on this is low if your environment is genuinely IKEv2-first. That’s what makes it good. A handful of hits a day, most of them explainable, is a rule the SOC will actually read instead of muting. The problem is the environments that aren’t IKEv2-first, and that’s where tuning starts.

The first tuning pass is about legacy clients, not the attack. Every Check Point remote-access deployment of any age has a residue of IKEv1: an old SecuRemote install on a machine finance won’t let you touch, a gateway-to-gateway tunnel to a partner that predates your standardization, a Spark box at a branch that an MSP configured in 2021 and nobody has logged into since. Those generate legitimate IKEv1 certificate sessions, and if you don’t baseline them out, the rule fires forty times the first day and gets disabled by Thursday. Pull two weeks of IKEv1 login events, bucket by user and source, and build the allowlist from what’s actually there. The residual set after that carve-out is small, and new entries to it are the interesting ones.

False positives after the legacy carve-out come from the usual remote-access noise. A real user on a genuinely new IP — new home ISP, traveling, phone hotspot — looks structurally similar to an attacker establishing a first session from a leased VPS. The discriminator that holds up is the pairing of scheme anomaly with source reputation: successful IKEv1 cert login from an ASN that belongs to a hosting provider rather than a residential or mobile carrier. That’s a two-signal correlation, and it cuts the noise hard without leaning on geo-velocity, which lies constantly for legitimately mobile users.

One more source of confusion worth naming: the certificate-versus-preshared distinction is not always clean in the exported logs. Mixed-mode gateways can produce login records where the method field is ambiguous or blank, and an ambiguous method on a successful session is not something to drop silently. Route those to a low-priority queue rather than the wildcard match. Treat blank or ambiguous authentication-method fields on completed IKEv1 sessions as hunt candidates rather than discarding them — but validate against your own log behavior before you read too much into the pattern. The public research proves the bypass; it does not establish that Check Point emits a blank method field for an exploited session, so this is a place to look, not a signature to trust.

Where the answer changes with the environment

If you already run IKEv2-only with mandatory machine-certificate auth and legacy client support disabled, you are largely out of the blast radius, and the detection above is a tripwire rather than a hunt. That configuration is the real control here, and it maps cleanly to CM-6 — the secure baseline is what neutralizes the vulnerability class, patch or no patch. Everyone else is choosing between an emergency hotfix window and a config change that breaks some users’ clients. Pick the config change where you can absorb the breakage; it’s durable in a way the hotfix isn’t.

Spark appliances at branch sites are the coverage gap that will bite. If an MSP manages them, their logs may never reach your index at all, and you’ll have neither the login events to hunt nor the ability to push the IKEv2 config. That’s not a detection problem, it’s an SA-9 external-services problem, and the answer is a contractual one about log forwarding and change control, not a SIEM rule. Name it in the risk register now, because “we couldn’t see the branch gateways” is a bad sentence to write in an incident report later.

On the retention question: if you’re auditing back to May 7 as Rapid7 recommends and your VPN logs live 30 days hot, 90 cold, you are reconstructing the earliest exposure window from cold storage or from nothing. The frozen-bucket restore on a Splunk cluster is not fast and not fun. Start it before you finish reading the advisory.

Control mapping

The center of gravity is identity. IA-2 first — the gateway authenticated an entity it never verified — with IA-8 alongside it wherever non-organizational or external identities are in scope. IA-5 for the certificate handling that got skipped. AC-17 covers the remote-access surface itself, and SC-23 is the session-authenticity guarantee the bug violates outright: the tunnel is established, but its authenticity was never established. And because the exploit leaves no forensic field to capture, the logging gap is as much an AU-3/AU-12 problem — audit content and audit-record generation — as it is a detection one.

Patch the gateways on the emergency track — that part isn’t in dispute. But treat the hotfix as the thing that stops the bleeding and the IKEv2 baseline as the thing that closes the wound. A bug that lets the client decide whether it gets checked is a bug your configuration can refuse to participate in, and configuration outlives any single CVE. The detection, meanwhile, was never going to catch the exploit. It catches the session the exploit leaves behind, and that’s the only artifact you were ever going to get.

Sources

• Check Point — Hotfix for vulnerabilities in the deprecated IKEv1 VPN protocol (advisory)
• Check Point sk185035 — CVE-2026-50752, site-to-site certificate bypass in deprecated IKEv1
• NVD — CVE-2026-50751 (CWE-287, CISA KEV date added 2026-06-08, due 2026-06-11)
• watchTowr Labs — Marking Your Own Homework: Check Point Remote Access VPN IKEv1 Authentication Bypass (CVE-2026-50751)
• Rapid7 — Critical Check Point VPN Zero-Day Exploited in the Wild (CVE-2026-50751)
• BleepingComputer — Check Point links VPN zero-day attacks to Qilin ransomware gang