A logic flow weakness in Remote Access and Mobile Access certificate validation in deprecated IKEv1 key…

CVE-2026-50751 is an authentication bypass on Check Point Remote Access VPN / Mobile Access when the gateway is configured to use deprecated IKEv1. The vulnerable path is only reachable when all of these are true: Remote Access or Mobile Access is enabled, IKEv1 is enabled for Remote Access, legacy/older clients are allowed, and machine certificate authentication is not mandatory. Affected branches called out by Check Point and national CERT mirrors include R81.20, R82, R82.10, plus several end-of-support lines and affected Spark builds.

The vendor's 9.3 CRITICAL rating is fair in practice. Yes, the exposed population is narrower than a generic internet-facing auth bypass because it depends on a deprecated configuration path, but the moment that path exists this lands on a perimeter VPN gateway, requires no credentials, is actively exploited, and is KEV-listed. The configuration friction shrinks prevalence; it does not shrink the consequence.

Why this verdict

• Baseline holds: Vendor 9.3 is not inflated for exposed systems because the chain starts with unauthenticated remote access from the internet and ends in a real VPN foothold.
• Friction audit — deprecated path only: I apply downward pressure for four prerequisites: internet-reachable Check Point VPN, Remote Access/Mobile Access enabled, IKEv1 enabled, legacy clients allowed, and machine cert not mandatory. Each prerequisite cuts reachable population, and requiring internal access is *not* part of the chain here — the attacker is external from the start.
• Modern controls only partly help: NGFW posture and good config hygiene should have removed IKEv1; IPS now detects known exploit traffic; EDR does nothing until after the VPN session exists. That means the preventive control is mostly configuration state, not a universal security backstop.
• Active exploitation cancels most downgrade: Check Point observed live attacks dating back to 2026-05-07, CISA added it to KEV on 2026-06-08, and Check Point published an IPS protection specifically referencing public PoCs. Once attackers are already using it, theoretical prevalence arguments get weaker.
• Role multiplier: Low-value role = lab or isolated branch gateway, where success yields a limited segment foothold. Typical role = line-of-business remote-access edge, where success yields tenant/internal user-network access. High-value role = enterprise perimeter VPN concentrator into AD-reachable networks, where the documented chain plausibly ends in domain or fleet compromise after post-auth pivoting. Because this is canonically a network edge appliance, the worst plausible role sets a CRITICAL floor.

Why not higher?

It is not a 10.0-style instant-catastrophe bug because exploitation yields a VPN session, not appliance RCE or immediate domain takeover. The attacker still has to do post-auth work, and the vulnerable state is limited to a deprecated configuration path rather than every default deployment.

Why not lower?

You cannot responsibly put this below CRITICAL when it is unauthenticated, internet-reachable, actively exploited, and affects a perimeter trust boundary. The IKEv1/legacy-client/machine-cert prerequisites reduce how many gateways are exposed, but they do not meaningfully soften the outcome for the gateways that are.

1. Disable IKEv1 for remote access — Force IKEv2-only for Remote Access immediately, within hours. This removes the vulnerable protocol path entirely and is the fastest compensating control when change windows are tighter than hotfix rollout.
2. Block legacy remote-access clients — Turn off the setting that allows older/legacy clients to connect, immediately within hours. The exploit depends on keeping that compatibility lane open.
3. Require machine certificates — Make machine certificate authentication mandatory immediately, within hours, on affected gateways where client population supports it. This breaks one of the key conditions called out by the vendor and CERT mirrors.
4. Enable and update IPS — Pull the latest Check Point IPS updates and enforce the protection for CVE-2026-50751 immediately, within hours. This is not a substitute for patching, but it adds exploit-path detection and blocking while gateway changes propagate.
5. Audit for compromise since 2026-05-07 — Review VPN, authentication, and post-auth activity logs back to 2026-05-07 immediately, within hours, because the vendor traced exploitation to that date. Prioritize new VPN sessions, unexpected geographies, and lateral movement from remote-access address pools.

Run this on each Check Point Gaia Security Gateway over SSH as admin with Expert mode or root. Save it as cve-2026-50751-check.sh and run bash cve-2026-50751-check.sh; it performs a gateway-side prescreen based on branch/take and active VPN listeners. It does not fully prove the legacy-client and machine-certificate settings on every build, so unsupported branches or partial data can return UNKNOWN.

#!/usr/bin/env bash
# CVE-2026-50751 prescreen for Check Point Gaia Security Gateway
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

unknown() {
  echo "UNKNOWN - $1"
  exit 2
}

vuln() {
  echo "VULNERABLE - $1"
  exit 1
}

patched() {
  echo "PATCHED - $1"
  exit 0
}

have_cmd() {
  command -v "$1" >/dev/null 2>&1
}

if ! have_cmd clish; then
  unknown "clish not found; this script is intended for Gaia gateways"
fi

VER_OUT="$(clish -c 'show version all' 2>/dev/null || true)"
[ -n "$VER_OUT" ] || unknown "could not read 'show version all' output"

# Normalize whitespace for easier matching
VER_ONE_LINE="$(printf '%s\n' "$VER_OUT" | tr '\n' ' ' | tr -s ' ')"

BRANCH=""
for b in R82.10 R82.00.X R82 R81.20 R81.10.X R81.10 R81 R80.40 R80.20.X; do
  if printf '%s' "$VER_ONE_LINE" | grep -q "$b"; then
    BRANCH="$b"
    break
  fi
done

[ -n "$BRANCH" ] || unknown "could not determine branch from version output"

TAKE="$(printf '%s' "$VER_ONE_LINE" | grep -Eo 'Take[[:space:]]+[0-9]+' | head -n1 | grep -Eo '[0-9]+' || true)"
BUILD="$(printf '%s' "$VER_ONE_LINE" | grep -Eo 'Build[[:space:]]+[0-9]+' | head -n1 | grep -Eo '[0-9]+' || true)"

VPN_LISTENER="no"
if have_cmd ss; then
  if ss -lun 2>/dev/null | grep -Eq ':(500|4500)[[:space:]]'; then
    VPN_LISTENER="yes"
  fi
elif have_cmd netstat; then
  if netstat -lun 2>/dev/null | grep -Eq ':(500|4500)[[:space:]]'; then
    VPN_LISTENER="yes"
  fi
fi

VPD_RUNNING="no"
if ps -ef 2>/dev/null | grep -E '[v]pnd|[i]ke' >/dev/null 2>&1; then
  VPD_RUNNING="yes"
fi

case "$BRANCH" in
  R82.10)
    [ -n "$TAKE" ] || unknown "R82.10 detected but could not parse Jumbo Hotfix Take"
    if [ "$TAKE" -ge 20 ]; then
      patched "R82.10 Take $TAKE is at or above fixed level (Take 20+)"
    fi
    if [ "$VPN_LISTENER" = "yes" ] || [ "$VPD_RUNNING" = "yes" ]; then
      vuln "R82.10 Take $TAKE is below fixed level (Take 20+) and VPN services appear active"
    fi
    unknown "R82.10 Take $TAKE is below fixed level, but active VPN state could not be confirmed"
    ;;
  R82)
    [ -n "$TAKE" ] || unknown "R82 detected but could not parse Jumbo Hotfix Take"
    if [ "$TAKE" -ge 104 ]; then
      patched "R82 Take $TAKE is at or above fixed level (Take 104+)"
    fi
    if [ "$VPN_LISTENER" = "yes" ] || [ "$VPD_RUNNING" = "yes" ]; then
      vuln "R82 Take $TAKE is below fixed level (Take 104+) and VPN services appear active"
    fi
    unknown "R82 Take $TAKE is below fixed level, but active VPN state could not be confirmed"
    ;;
  R81.20)
    [ -n "$TAKE" ] || unknown "R81.20 detected but could not parse Jumbo Hotfix Take"
    if [ "$TAKE" -ge 142 ]; then
      patched "R81.20 Take $TAKE is at or above fixed level (Take 142+)"
    fi
    if [ "$VPN_LISTENER" = "yes" ] || [ "$VPD_RUNNING" = "yes" ]; then
      vuln "R81.20 Take $TAKE is below fixed level (Take 142+) and VPN services appear active"
    fi
    unknown "R81.20 Take $TAKE is below fixed level, but active VPN state could not be confirmed"
    ;;
  R81.10|R81|R80.40|R80.20.X)
    if [ "$VPN_LISTENER" = "yes" ] || [ "$VPD_RUNNING" = "yes" ]; then
      vuln "$BRANCH is an end-of-support affected branch and VPN services appear active"
    fi
    unknown "$BRANCH is an end-of-support affected branch, but active VPN state could not be confirmed"
    ;;
  R82.00.X|R81.10.X)
    # Spark builds are affected, but Gaia parsing is inconsistent across appliance families.
    if [ -n "$BUILD" ]; then
      if [ "$BRANCH" = "R82.00.X" ] && [ "$BUILD" -ge 998002216 ]; then
        patched "Spark $BRANCH Build $BUILD is at or above fixed level (998002216+)"
      fi
      if [ "$BRANCH" = "R81.10.X" ] && [ "$BUILD" -ge 996004901 ]; then
        patched "Spark $BRANCH Build $BUILD is at or above fixed level (996004901+)"
      fi
      if [ "$VPN_LISTENER" = "yes" ] || [ "$VPD_RUNNING" = "yes" ]; then
        vuln "Spark $BRANCH Build $BUILD appears below fixed level and VPN services appear active"
      fi
      unknown "Spark $BRANCH Build $BUILD appears below fixed level, but active VPN state could not be confirmed"
    fi
    unknown "Spark branch detected but build parsing was not reliable on this host"
    ;;
  *)
    unknown "unhandled branch '$BRANCH'"
    ;;
esac

Sources

1. NVD CVE-2026-50751
2. Check Point security advisory blog
3. Check Point IPS advisory CPAI-2026-7109
4. Rapid7 emerging threat response
5. IPA Japan alert with affected/fixed versions
6. CERT Santé advisory with fixed minimum takes/builds
7. Help Net Security on public WatchTowr PoC research