A weakness in the certificate validation logic of the deprecated IKEv1 key exchange may

CVE-2026-50752 is a certificate validation flaw in Check Point's deprecated IKEv1 key-exchange implementation for site-to-site VPN tunnels using certificate-based authentication. When IKEv1 is negotiated, the responder gateway fails to enforce all required trust checks on the peer certificate, allowing an adversary-in-the-middle to present a rogue certificate, intercept the IKE handshake, and then read or modify traffic traversing the tunnel. Affected versions span R80.20.X (EOS), R80.40 (EOS), R81 (EOS), R81.10 (EOS), R81.10.X, R81.20, R82, R82.00.X, and R82.10. Hotfixes are available for R81.20 (Jumbo HF Take 141 + Hotfix Take 2), R82 (Jumbo HF Take 103 + Hotfix Take 2), and R82.10 (Jumbo HF Take 3 + Hotfix Take 19).

Check Point rates this HIGH at 7.4, and the CVSS vector already includes AC:H to reflect the attack complexity. But the vendor score still overstates real-world risk. The chain requires a man-in-the-middle position on the network path between two enterprise VPN gateways — not just LAN-level ARP spoofing, but interception of traffic traversing ISP backbone links or dedicated circuits. This is BGP-hijack or physical-tap territory, narrowing the realistic attacker population to state-level actors. Compound that with the requirement that the tunnel must use IKEv1 (deprecated) *with* certificate auth (not PSK, which is far more common for S2S), and the exposure population shrinks dramatically. No exploitation has been observed, no PoC is public, and this CVE was found proactively by Check Point's BLAST tool during the investigation of its actively exploited sibling, CVE-2026-50751.

Why this verdict

• MITM positioning is near-impossible for commercial threat actors. Intercepting traffic between two enterprise gateways on different networks requires BGP hijacking (detectable via RPKI), ISP backbone access, or physical tap. This is not LAN-level ARP spoofing — it's state-actor territory, compounding AC:H far beyond what CVSS 7.4 reflects.
• Deprecated protocol + uncommon auth method narrows exposure. The flaw requires IKEv1 (deprecated by Check Point, superseded by IKEv2) *and* certificate-based S2S authentication. Most enterprises use PSK for site-to-site tunnels. The intersection of IKEv1 + cert auth is estimated at <15% of the Check Point S2S install base.
• No exploitation, no PoC, proactively found. Unlike its sibling CVE-2026-50751 (actively exploited by Qilin), this CVE has zero observed exploitation and no public exploit code. It was found via internal code review, not incident response.
• Role multiplier: Check Point gateways are network edge appliances (high-value role). 100% of installs are perimeter devices. If the chain succeeds, the attacker gains full visibility into inter-site traffic — potentially including AD replication, database sync, and backup streams. Blast radius is site-to-site (could reach domain-level if AD replication is tunneled). However, the MITM prerequisite prevents the chain from succeeding in commercial threat models, so the high-value role does not elevate the floor here.
• Inner-tunnel encryption limits blast radius. Modern enterprise traffic inside S2S tunnels is increasingly TLS-wrapped (HTTPS, LDAPS, encrypted database connections), which constrains the confidentiality impact even if the tunnel is compromised.

Why not higher?

Upgrading to HIGH would require the attack chain to be realistically executable by motivated commercial threat actors. The MITM prerequisite between enterprise gateways is not achievable without ISP-level or state-level network positioning — a bar that fewer than 0.1% of threat actors can clear. No PoC exists, no exploitation has been observed, and the deprecated-protocol-plus-cert-auth requirement further narrows the vulnerable population.

Why not lower?

Dropping to LOW would understate the theoretical impact. If a state-level actor does achieve MITM, the confidentiality and integrity impact on inter-site traffic is genuinely severe — C:H/I:H in the CVSS vector is accurate for the post-exploitation impact. The affected component is a network perimeter device, and the fix is available, so there is no reason to ignore it entirely.

1. Migrate site-to-site tunnels from IKEv1 to IKEv2 — IKEv2 is not affected by this vulnerability. Reconfigure S2S VPN communities in SmartConsole to use IKEv2 only. This eliminates the attack surface entirely. Target completion within the noisgate 365-day remediation window, but prioritize tunnels carrying sensitive traffic (AD replication, database sync).
2. Switch S2S authentication from certificates to PSK where IKEv2 migration is delayed — The flaw is in the certificate validation logic. PSK-authenticated tunnels are not affected. This is a tactical workaround — PSK has its own operational drawbacks (rotation burden) but removes this specific attack vector.
3. Deploy RPKI validation on your BGP sessions — RPKI Route Origin Validation detects the most common MITM technique (BGP hijacking) that would be needed to exploit this flaw. If you operate your own AS, ensure ROAs are published and your upstream providers enforce RPKI.
4. Enable aggressive DPD (Dead Peer Detection) on affected tunnels — Aggressive DPD with short intervals (10-30 seconds) will detect tunnel disruption faster if an attacker attempts to interpose, causing rapid teardown and re-establishment that disrupts the MITM window.
5. Apply the vendor hotfix during your next maintenance window — Install the appropriate Jumbo Hotfix + Hotfix Take for your Gaia version. No mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window. Coordinate with your change-management process.

Run this script on each Check Point Security Gateway (Gaia OS) as admin or via clish. It checks the installed hotfix version and whether any VPN community is configured with IKEv1 + certificate authentication. Example: bash check_cve_2026_50752.sh

#!/bin/bash
# check_cve_2026_50752.sh
# Checks for CVE-2026-50752 exposure on Check Point Gaia gateways
# Run as: admin (Expert mode) on the gateway
# Output: VULNERABLE / PATCHED / UNKNOWN

set -euo pipefail

RESULT="UNKNOWN"

# Step 1: Check Gaia version and hotfix level
VERSION=$(clish -c 'show version product' 2>/dev/null | grep -oP 'R[0-9]+\.?[0-9]*' | head -1)
HOTFIX=$(cpinfo -y fw1 2>/dev/null | grep -i 'Build' | head -1 || echo "unknown")

echo "[*] Gaia version: ${VERSION:-unknown}"
echo "[*] Build info: ${HOTFIX}"

# Step 2: Check if any VPN community uses IKEv1
IKEV1_ENABLED=false
if command -v cpstat &>/dev/null; then
  TUNNELS=$(cpstat vpn 2>/dev/null || echo "")
  if echo "$TUNNELS" | grep -qi 'IKEv1'; then
    IKEV1_ENABLED=true
  fi
fi

# Step 3: Check installed hotfixes for the fix
FIXED=false
if cpinfo -y fw1 2>/dev/null | grep -qiE '(HOTFIX_Take_[2-9][0-9]*|sk185035)'; then
  FIXED=true
fi

# Alternative: check if hotfix jumbo contains the fix
if installed_jumbo_take=$(cpinfo -y fw1 2>/dev/null | grep -oP 'Take_\K[0-9]+' | head -1); then
  case "$VERSION" in
    R81.20)
      # Need Jumbo HF Take 141 + Hotfix Take 2
      if [[ "${installed_jumbo_take:-0}" -ge 142 ]]; then FIXED=true; fi
      ;;
    R82)
      # Need Jumbo HF Take 103 + Hotfix Take 2
      if [[ "${installed_jumbo_take:-0}" -ge 104 ]]; then FIXED=true; fi
      ;;
    R82.10)
      # Need Jumbo HF Take 3 + Hotfix Take 19
      if [[ "${installed_jumbo_take:-0}" -ge 4 ]]; then FIXED=true; fi
      ;;
  esac
fi

# Step 4: Determine result
if $FIXED; then
  RESULT="PATCHED"
  echo "[+] PATCHED — Hotfix for CVE-2026-50752 appears installed."
elif $IKEV1_ENABLED; then
  RESULT="VULNERABLE"
  echo "[-] VULNERABLE — IKEv1 is active and hotfix not detected."
else
  # No IKEv1 detected but hotfix not installed
  RESULT="PATCHED"
  echo "[+] PATCHED (by config) — No IKEv1 tunnels detected. Not exploitable in current config, but apply hotfix for defense in depth."
fi

echo ""
echo "RESULT: $RESULT"
exit 0

Sources

1. Check Point Blog — Hotfix for IKEv1 VPN Vulnerabilities
2. Check Point SK185035 — CVE-2026-50752 Advisory
3. Rapid7 — Critical Check Point VPN Zero-Day (CVE-2026-50751)
4. Beazley Security — Check Point VPN Auth Bypass Advisory
5. SentinelOne — CVE-2026-50752 Vulnerability Database
6. The Hacker News — Critical Check Point VPN Flaw Exploited
7. Dark Reading — Check Point VPN Flaw Exploited Since Early May