Vulnerability Analysis

CVE-2026-50751: Check Point VPN IKEv1 Authentication Bypass Exploited by Qilin Ransomware

Executive Summary

CVE-2026-50751 is a critical authentication bypass (CVSS 9.3) in Check Point's Remote Access VPN, Mobile Access, and Spark Firewall products, rooted in deprecated IKEv1 key exchange code. An unauthenticated attacker can send a crafted Vendor ID payload to let the gateway skip all certificate and signature validation — effectively walking through the front door without credentials. Exploitation has been active since at least May 7, 2026 (a full month before any patch existed), has been linked to Qilin ransomware deployments, and CISA added it to the Known Exploited Vulnerabilities catalog on June 8, 2026 with a three-day remediation deadline for federal agencies.

1. What Is This Vulnerability?

At its core, CVE-2026-50751 is a case of client-controlled authentication: the Check Point gateway allows the connecting client to supply a bitmask that tells the server how carefully it should verify the client's identity. Set the right bit, and the gateway skips signature verification entirely.

The Root Cause: processVendorIDPayload

During IKEv1 Main Mode negotiation, gateways parse "Vendor ID" payloads from the client — a standard IKE mechanism for capability advertising. Check Point's iked daemon recognizes a proprietary payload with the 16-byte magic:

3c f1 87 b2 47 40 29 ea 46 ac 7f d0 ea f2 89 f5  ("VPNExtFeatures")

The handler reads the four bytes immediately following this magic and writes them — byte-swapped — directly into an authentication flags register at offset 0x4bc4 in the phase-1 negotiation state:

// processVendorIDPayload(): reconstructed from disassembly (vulnerable R82.10 T19)
int trailing = vid_len - 16;          // bytes after the 16-byte magic
if (trailing <= 3)
    return ...;                       // need at least 4 trailing bytes

uint cap = *(uint *)(vid + 16);       // [1] read 4 attacker-supplied bytes
*(uint *)(state + 0x4bc4) = bswap32(cap); // [2] store as auth flags — verbatim

At [1], the client's four bytes are taken at face value. At [2], they become the authoritative auth-decision register for the entire session.

How Authentication Gets Skipped

Two separate gate checks in the IKE processing code both read from state + 0x4bc4:

Gate 1 — verify_peer_auth (phase-1 signature check):

peer_flags = state[0x4bc4];
if ((((byte)peer_flags & 4) != 0) ||         // bit 0x4 set → short-circuit
    (verifyMessagePhase1(...) >= 0)) {
    return 0;   // AUTH SUCCESS
}

If bit 0x4 is set, the || short-circuits and verifyMessagePhase1 — the function that verifies the client actually holds the private key behind its certificate — never runs.

Gate 2 — process_auth_pl (certificate processing):

peer_flags = *(uint *)(state + 0x4bc4);
check_sig  = peer_flags & 2;                   // bit 0x2
process_cert_payloads(msg, state, err, check_sig);

if ((check_sig != 0) &&
    (seekPayload(0xf9, ...) >= 0)) {           // 0xF9 = signature payload
    processSigPayload(...);                     // only reached if bit 0x2 is set
}

If bit 0x2 is clear, the machine-certificate payloads and the signature payload are never processed.

The exploit in one sentence: send VPNExtFeatures with trailing bytes 00 00 00 04 (bit 0x4 set), and both authentication gates stand down.

Attack Vector

An attacker needs only to:

  1. Know a valid VPN username. The gateway distinguishes "username not found" from "authentication failed," making the same probe a username oracle.
  2. Know the Internal CA organization string (O= in the gateway's DN). This is embedded in the gateway's own public TLS certificate — publicly readable.

The attacker then:

  • Opens an IKEv1 Main Mode session to UDP 500/4500 (or falls back to TCP 443 via Check Point "Visitor Mode" when UDP is filtered).
  • Includes the VPNExtFeatures Vendor ID with 0x00000004 as the trailing capability dword.
  • Sends a self-signed, throwaway certificate with a completely random signature.
  • The gateway logs "vendorid = 0 ... not a Check Point peer" and then authenticates the session anyway.

The result: a valid VPN session established with zero valid credentials.

$ python3 exploit.py -u <valid_username>
[+] Self-signed cert (untrusted); signature will be invalid (no private key)
[+] Gateway Internal IP: 172.31.255.128
[+] [BYPASSED] Gateway authenticated us. CVE-2026-50751 confirmed.

What the Patch Fixed

The patch (applied in sk185033) removes the client-controlled parameter entirely from process_cert_payloads and replaces it with a read of the gateway's own configured policy:

// PATCHED version:
cert_mode     = *(int *)(state + 0x4bd4);             // read gateway policy, not client flags
cert_required = is_machine_cert_supported(cert_mode); // enforce server-side decision
if (cert_required != '\0') {
    while (seekPayload(0xf6, ...) >= 0) {
        processCertPayload(...);
    }
}

The gateway now decides what to check — the client no longer gets a vote.

Real-World Impact

Active exploitation began on May 7, 2026 — roughly five weeks before Check Point published the advisory or any patch was available. Rapid7 confirmed two high-confidence cases. Check Point attributes the campaign with medium confidence to a Qilin ransomware affiliate, with post-exploitation chains including ELF payload retrieval from attacker-controlled VPS infrastructure and eventual ransomware deployment.

2. Who Is Affected?

All Check Point gateways with Remote Access VPN or Mobile Access blades running these versions, where:

  • Legacy Remote Access clients are accepted (IKEv1 not disabled), AND
  • Machine Certificate Authentication is not set to mandatory
Version Branch Support Status Hotfix Available
R80.20.X End of Support No — must upgrade
R80.40 End of Support No — must upgrade
R81 End of Support No — must upgrade
R81.10 End of Support No — must upgrade
R81.10.X Active Yes — sk185033
R81.20 Active Yes — sk185033
R82 Active Yes — sk185033
R82.00.X Active Yes — sk185033
R82.10 Active Yes — sk185033

Authentication modes vulnerable (over both UDP 500/4500 and TCP 443):

  • Certificate
  • Certificate with enrollment
  • Mixed

Not bypassed by this specific flaw: legacy username/password (XAUTH) mode — the XAUTH password exchange happens after IKE phase-1 and still requires a valid credential.

3. How to Detect It (Testing)

Check Your Exposure Conditions

Before testing, confirm whether your gateways are in the affected configuration:

# On the Check Point gateway (clish):
show vpn ike-v1 enabled
show remote-access community <name> authentication-method

If IKEv1 is not explicitly disabled and certificate auth is not mandatory, assume you are exposed.

Manual Testing Steps

Step 1: Check for the vulnerable configuration via SmartConsole

  • Open SmartConsole → Global Properties → Remote Access → VPN Authentication and Encryption
  • Verify "IKEv2 only" is NOT enforced (if it is, you are mitigated)
  • Check whether "Machine Certificate Authentication" is set to "Required" vs "Optional" or "Disabled"

Step 2: Review gateway logs for exploitation indicators

  • In SmartLog or via CLI, search for IKEv1 Main Mode sessions since May 7, 2026
  • Flag entries containing: "vendorid = 0" combined with "IkeSAFromState: User ... saved" — this is the gateway authenticating a session while simultaneously logging that the peer is unrecognized
# SmartLog query:
blade:"VPN" AND action:"Accept" AND message:"IkeSAFromState" AND message:"vendorid = 0"

Step 3: Cross-reference VPN sessions against known-good user behavior

  • Pull Remote Access VPN session logs from May 7 onward
  • Compare source IPs against user baselines — attacker IPs originate from VPS providers (Kaupo Cloud HK, Shock Hosting, Vultr)

Step 4: Inspect IKE daemon logs directly

# On the gateway:
grep -E "IkeSAFromState|verify_peer_auth|vendorid = 0" /var/log/messages* | grep -v "Check Point peer"

Sessions where vendorid = 0 precedes a successful IkeSAFromState entry are exploitation artifacts.

Automated Scanning

Tenable / Nessus:

  • Plugin: Check for CVE-2026-50751 (available in feeds post June 9, 2026)
  • InsightVM/Nexpose: Check available in June 9 content release

Network-level exposure check:

# Probe whether UDP 500 or 4500 is reachable
nmap -sU -p 500,4500 <gateway-ip>
# Check if TCP 443 responds to TCPT (Visitor Mode)
curl -k -o /dev/null -w "%{http_code}" https://<gateway-ip>/

Rapid7 InsightIDR / MDR detection rules (available):

  • Suspicious Network Connection - Critical Check Point VPN Zero-Day Exploited in the Wild (CVE-2026-50751)
  • Suspicious Process - Critical Check Point VPN Zero-Day Exploited in the Wild (CVE-2026-50751)

Code Review / Configuration Checklist

For Check Point administrators:

  • Confirm IKEv1 is disabled or IKEv2-only mode is enforced in Remote Access settings
  • Verify Machine Certificate Authentication is set to "Required" (not "Optional")
  • Confirm the legacy Remote Access client (SecureClient/Endpoint Security VPN older clients) is not enabled
  • IPS blade is enabled and signatures are current
  • Review access logs from May 7, 2026 onward for anomalous VPN sessions

4. How to Fix It (Mitigation)

Step-by-Step Remediation

Option A: Apply the hotfix (strongly preferred)

  1. Log into the Check Point Support Portal and navigate to sk185033.
  2. Download the hotfix for your version: R81.10.X, R81.20, R82, R82.00.X, or R82.10.
  3. Apply via CPUSE (Check Point Unified Software Upgrade Environment): 
    # On the gateway (expert mode):
cpuse install <hotfix-package-name>
  4. Reboot the gateway if prompted.
  5. Verify the hotfix is installed: 
    cpinfo -y all | grep sk185033

Option B: Immediate configuration mitigations (if patching must be delayed)

Implement all of the following simultaneously:

  1. Disable legacy Remote Access client support:

    • SmartConsole → Global Properties → Remote Access → uncheck "Support legacy SecureClient/SNX clients"

  2. Force IKEv2 only:

    • SmartConsole → Global Properties → Remote Access → VPN Authentication → set to "IKEv2 only"

  3. Require Machine Certificate Authentication:

    • SmartConsole → Gateway object → IPSec VPN → Remote Access → set "User authentication method" to "Certificate" AND check "Require machine certificate"

  4. Enable IPS and update signatures:

    # In SmartConsole → Threat Prevention → IPS → update now
# Or via CLI:
cpstat os -f all
dynamic_objects -l | grep IPS

  5. Install policy to push all changes:

    • SmartConsole → Install Policy → select all gateways → Install

For End-of-Support versions (R80.20.X, R80.40, R81, R81.10): No hotfix is available. Apply configuration mitigations above and immediately plan migration to a supported release. These versions are actively targeted.

Configuration Hardening (Before/After)

# BEFORE (vulnerable default for many deployments):
Remote Access Authentication: Certificate (Optional machine cert)
IKE Version: IKEv1 and IKEv2 supported
Legacy clients: Enabled

# AFTER (hardened):
Remote Access Authentication: Certificate (Machine cert REQUIRED)
IKE Version: IKEv2 only
Legacy clients: Disabled
IPS: Enabled + latest signatures

5. How to Test the Fix (Validation)

Regression Test Scenarios

Scenario A: Verify exploitation no longer works After applying the hotfix or mitigations, use the watchTowr detection artifact generator (PoC) against your patched gateway and confirm it returns an authentication failure.

Expected patched-gateway log:

verifyMessagePhase1: Authentication failure with hybrid

(vs. the vulnerable gateway's: IkeSAFromState: User <name> saved)

Scenario B: Verify legitimate VPN users are not broken

  • Test VPN connectivity with a fully valid client certificate and private key
  • Confirm connection establishes successfully
  • Test all certificate authentication modes in use across your user base

Scenario C: Verify IKEv1 is blocked (if enforced) Attempt an IKEv1 handshake from a test client. The gateway should refuse the session:

ike-scan -M --ikev1 <gateway-ip>
# Expected: no proposal chosen / connection refused

Security Test Cases

Test Case 1: Authentication bypass no longer accepted

  • Precondition: Hotfix applied, or IKEv2-only + mandatory machine cert enforced
  • Steps: Send VPNExtFeatures VID with 0x00000004 trailing bytes + self-signed cert + random signature
  • Expected result: Gateway returns NOTIFY authentication failed

Test Case 2: Username oracle behavior eliminated

  • Steps: Attempt IKEv1 session with a nonexistent username
  • Expected result: Connection rejected at the IKE layer before any username lookup occurs

Test Case 3: Visitor Mode (TCP 443) also protected

  • Steps: Repeat Test Case 1 targeting port TCP 443 with TCPT framing
  • Expected result: Same rejection behavior as UDP path

Automated Tests (Log Validation)

After any patching or configuration change, run this log audit to confirm no exploitation artifacts remain undetected since May 7, 2026:

# On the gateway (expert mode):
grep -E "IkeSAFromState.*saved" /var/log/messages* \
  | awk '{print $0}' \
  | while read line; do
      ts=$(echo "$line" | awk '{print $1, $2, $3}')
      user=$(echo "$line" | grep -oP 'User \K[^\s]+')
      echo "Session: $ts | User: $user"
    done

# Cross-reference with sessions that logged "vendorid = 0" in the same time window
grep "vendorid = 0" /var/log/messages* | grep -v "Check Point peer"

Any matches from before June 8, 2026 should be treated as potential compromise events requiring IR investigation.

6. Prevention & Hardening

Best Practices

Retire IKEv1: This vulnerability exists entirely in deprecated IKEv1 code. Every new deployment should enforce IKEv2 exclusively. IKEv1 has a history of cryptographic weaknesses independent of this bug and should not be active in any production VPN.

Enforce Machine Certificate Authentication: Certificate-based auth is only as strong as the enforcement of private-key ownership. Mandatory machine certificates (not optional) ensure the gateway actually verifies the client possesses the corresponding private key.

Minimize legacy client support: Legacy VPN clients (older Check Point SecureClient, early SNX versions) are a consistent source of protocol-level exposure. Audit your user base and retire legacy clients, then disable support at the gateway level.

Segment post-VPN access: Assume VPN authentication can be bypassed. Implement network segmentation and require additional authentication (MFA, zero-trust policy enforcement) for access to sensitive resources even from authenticated VPN sessions.

Maintain patching cadence: This vulnerability was exploited for 32 days before a patch existed. While you cannot always have a patch for a zero-day, you can reduce dwell time by monitoring for anomalous VPN behavior and maintaining current IPS signatures.

Monitoring & Detection

Indicators of Compromise (from Check Point's advisory):

Attacker IP addresses:

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

Malicious file hashes (MD5):

52fda5c1b9704544f32ee98d9060e689
51d39aa39478beeac94f2d12f682ecce

Behavioral detection rules to implement:

  • Alert on IKEv1 sessions from IPs not in your expected user population geography
  • Alert on VPN sessions established outside business hours for accounts with no history of off-hours access
  • Alert on ELF binary downloads initiated from the gateway's internal network shortly after VPN session establishment
  • Alert on VPN sessions where the source IP belongs to Vultr, Shock Hosting, or Kaupo Cloud ASNs

SIEM query (Splunk example):

index=firewall sourcetype=checkpoint action=allow blade=VPN protocol=IKE
| where (src_ip IN ("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"))
| stats count by src_ip, user, _time
| where _time >= relative_time(now(), "-40d@d")

Log monitoring for exploitation signature:

# Ongoing gateway log watch:
tail -f /var/log/messages | grep -E "(IkeSAFromState.*saved|vendorid = 0)" \
  | grep -v "Check Point peer"

References

Latest from the blog

See all →