Check Point Remote Access VPN / Mobile Access IKEv1 authentication bypass

I could not validate CVE-2026-50571 as an authoritative record. The vendor, NVD, and public technical writeups all point to the issue being CVE-2026-50751, and several public posts appear to have typoed the ID as 50571. The underlying flaw is a logic error in Check Point Remote Access VPN / Mobile Access over deprecated IKEv1 that lets an unauthenticated attacker establish a VPN session without a valid password if the gateway is configured to allow legacy Remote Access clients, permit IKEv1, and not require a machine certificate. Affected branches called out publicly include R80.20.X, R80.40, R81, R81.10, R81.10.X, R81.20, R82, R82.00.X, and R82.10, with EOS branches especially ugly because some do not receive normal long-term fixes.

Even after a friction audit, this stays critical in practice. Yes, not every Check Point gateway is reachable through this chain; the attack needs a specific legacy VPN posture. But the decisive fact is that this is a network-edge authentication bypass on a VPN concentrator, and Check Point confirmed active exploitation with at least one Qilin-linked post-compromise case. On a perimeter access control, 'narrower than all installs' is not enough to save it from the top bucket.

Why this verdict

• Identifier correction: authoritative sources consistently resolve this incident to CVE-2026-50751, not CVE-2026-50571; I am assessing the discovered real issue rather than the mistyped ID
• Active exploitation: Check Point said exploitation started by 2026-05-07, and NVD records KEV added 2026-06-08 for the authoritative ID; that alone is strong upward pressure
• Unauthenticated remote edge access: attacker position is unauthenticated remote. No phishing, stolen creds, or prior foothold is required to reach the vulnerable handshake path
• Friction audit — config gating: the chain only works where IKEv1 is enabled, legacy Remote Access clients are accepted, and machine certificates are not mandatory. Each of those requirements cuts real-world exposure below the full Check Point install base
• Friction audit — username dependency: the attacker still needs a valid user identity to map the forged cert subject. That is a real but modest brake because the protocol behavior can act as a username oracle and enterprise usernames are often guessable
• Friction audit — post-auth is not instant DA: exploitation yields a VPN session, not instant code exec on the gateway and not automatic domain admin. Segmentation, NAC, MFA on downstream apps, and EDR can still blunt the second stage
• Role multiplier: in the low-value role case, if this is a lab or tightly isolated sandbox gateway, the chain succeeds but blast radius may stay at host/segment scale
• Role multiplier: in the typical role case, this is a corporate remote-access gateway. The same chain succeeds and the blast radius becomes tenant/internal network scale because the attacker is now inside your trust boundary as a remote user
• Role multiplier: in the high-value role case, this is a canonical network-edge appliance fronting enterprise remote access. If the chain succeeds, the outcome is a fleet compromise path via internal lateral movement, credential harvesting, and ransomware staging; under the hard rule, that keeps the floor at CRITICAL for this product class

Why not higher?

It is not a straight 10.0 because exploitation is not universal across all deployments. The vulnerable path depends on a legacy IKEv1 posture, acceptance of legacy clients, and non-mandatory machine certificates, and the initial win is a VPN foothold rather than one-packet gateway RCE.

Why not lower?

Because this is a perimeter trust broker, not a back-office app. The chain starts from the internet with no authentication, is confirmed in active exploitation, and lands the attacker *inside* the network boundary; those facts swamp the configuration friction.

1. Disable IKEv1 for remote access — This is the cleanest blast-door shutoff because the vulnerable path lives in deprecated IKEv1. Where operationally possible, move Remote Access / Mobile Access to IKEv2-only and deploy within 3 days for a CRITICAL finding; if you have active exposure, do it within hours.
2. Stop accepting legacy Remote Access clients — The public exploit chain needs gateways to accept legacy clients. If you cannot patch immediately, disable legacy client acceptance as an interim control and complete the change within 3 days; validate client compatibility before broad rollout.
3. Require machine certificates — Mandatory machine-certificate authentication breaks a key prerequisite in the published chain. Use this where business dependencies prevent immediate protocol migration, and push it within 3 days as a compensating control.
4. Enable the IPS protection for the public PoC — Check Point published CPAI-2026-7109 specifically for public PoC traffic. Update IPS and install policy immediately, within hours on gateways that must stay online before the hotfix is completed.
5. Hunt VPN and iked logs for anomalies — Review logs back to at least 2026-05-07 for odd certificate-auth attempts, suspicious vendor IDs, unexpected geographies, and sessions linked to users who should not have used cert-based login. Start this immediately because compromise may predate disclosure.
6. Constrain post-VPN reachability — If you cannot eliminate exposure on day one, reduce the blast radius of a successful bypass by tightening VPN user network scopes, NAC rules, and segmentation. Treat this as a within 3 days emergency containment measure, not a replacement for patching.

Run this on the Check Point gateway itself from Expert mode as root or an admin that can execute clish and read local logs/config. Invoke it as bash ./check_cve_2026_50751.sh; it performs a best-effort local triage for the mapped issue (CVE-2026-50751) by checking version/take and looking for likely config indicators of IKEv1, legacy-client acceptance, and machine-certificate requirements.

#!/usr/bin/env bash
# check_cve_2026_50751.sh
# Best-effort local triage for the issue commonly mistyped as CVE-2026-50571,
# but authoritatively tracked as CVE-2026-50751.
#
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

say() { printf '%s\n' "$*"; }
fail_unknown() { say "UNKNOWN: $*"; exit 2; }

need_cmd() {
  command -v "$1" >/dev/null 2>&1 || fail_unknown "required command not found: $1"
}

need_cmd clish
need_cmd grep
need_cmd awk

TMP_VER="$(mktemp)"
TMP_CFG="$(mktemp)"
trap 'rm -f "$TMP_VER" "$TMP_CFG"' EXIT

clish -c "show version all" >"$TMP_VER" 2>/dev/null || fail_unknown "unable to run 'clish -c show version all'"
clish -c "show configuration" >"$TMP_CFG" 2>/dev/null || true

VER_TXT="$(tr '\n' ' ' < "$TMP_VER")"
CFG_TXT="$(tr '\n' ' ' < "$TMP_CFG" | tr '[:upper:]' '[:lower:]')"

# Try to locate hotfix fingerprint first.
if command -v cpinfo >/dev/null 2>&1; then
  if cpinfo -y all 2>/dev/null | grep -qi 'sk185033'; then
    say "PATCHED: hotfix identifier sk185033 found in cpinfo output"
    exit 0
  fi
fi

BRANCH=""
TAKE=""

# Parse common release strings.
if echo "$VER_TXT" | grep -q 'R82\.10'; then
  BRANCH='R82.10'
elif echo "$VER_TXT" | grep -q 'R82\.00\| R82 '; then
  BRANCH='R82'
elif echo "$VER_TXT" | grep -q 'R81\.20'; then
  BRANCH='R81.20'
elif echo "$VER_TXT" | grep -q 'R81\.10\.X\|R81\.10'; then
  BRANCH='R81.10'
elif echo "$VER_TXT" | grep -q 'R81 '; then
  BRANCH='R81'
elif echo "$VER_TXT" | grep -q 'R80\.40'; then
  BRANCH='R80.40'
elif echo "$VER_TXT" | grep -q 'R80\.20'; then
  BRANCH='R80.20'
fi

TAKE="$(echo "$VER_TXT" | grep -Eoi 'take[[:space:]]+[0-9]+' | awk '{print $2}' | head -n1)"

# Best-effort exposure heuristics from exported config.
# These are intentionally conservative and may return UNKNOWN if config is opaque.
IKEV2_ONLY=0
IKEV1_ENABLED=0
LEGACY_ALLOWED=0
MACHINE_CERT_REQUIRED=0

if [ -s "$TMP_CFG" ]; then
  echo "$CFG_TXT" | grep -Eq 'ike_v2_only|ikev2-only|ikev2 only' && IKEV2_ONLY=1
  echo "$CFG_TXT" | grep -Eq 'ikev1|remote access.*ike' && IKEV1_ENABLED=1
  echo "$CFG_TXT" | grep -Eq 'legacy.*remote access|accept.*legacy|legacy.*client' && LEGACY_ALLOWED=1
  echo "$CFG_TXT" | grep -Eq 'machine.*cert.*required|required.*machine.*cert' && MACHINE_CERT_REQUIRED=1
fi

# Version logic based on public downstream advisories:
# - R82.10 vulnerable at Take 19 or below
# - R82 vulnerable at Take 103 or below
# - R81.20 vulnerable at Take 141 or below
# Older / EOS branches are treated as potentially vulnerable unless proven patched.
VERSION_VULN=0
VERSION_UNKNOWN=0

case "$BRANCH" in
  'R82.10')
    if [ -n "$TAKE" ]; then
      [ "$TAKE" -le 19 ] && VERSION_VULN=1 || VERSION_VULN=0
    else
      VERSION_UNKNOWN=1
    fi
    ;;
  'R82')
    if [ -n "$TAKE" ]; then
      [ "$TAKE" -le 103 ] && VERSION_VULN=1 || VERSION_VULN=0
    else
      VERSION_UNKNOWN=1
    fi
    ;;
  'R81.20')
    if [ -n "$TAKE" ]; then
      [ "$TAKE" -le 141 ] && VERSION_VULN=1 || VERSION_VULN=0
    else
      VERSION_UNKNOWN=1
    fi
    ;;
  'R81.10'|'R81'|'R80.40'|'R80.20')
    VERSION_VULN=1
    ;;
  *)
    VERSION_UNKNOWN=1
    ;;
esac

# Decide.
if [ "$VERSION_UNKNOWN" -eq 1 ]; then
  fail_unknown "could not confidently determine gateway branch/take from local output"
fi

if [ "$VERSION_VULN" -eq 0 ]; then
  say "PATCHED: branch/take appears newer than the publicly listed vulnerable baseline for the mapped issue"
  exit 0
fi

# For vulnerable versions, assess config prerequisites.
# If config clearly looks safe, return PATCHED only in the sense of 'not exposed to this chain' is NOT appropriate.
# The host is still on vulnerable code, so return UNKNOWN rather than PATCHED when config is inconclusive or restrictive.
if [ "$IKEV2_ONLY" -eq 1 ]; then
  fail_unknown "gateway version appears vulnerable, but config suggests IKEv2-only; exploit path may be blocked, code still needs hotfix"
fi

if [ "$IKEV1_ENABLED" -eq 1 ] && [ "$LEGACY_ALLOWED" -eq 1 ] && [ "$MACHINE_CERT_REQUIRED" -eq 0 ]; then
  say "VULNERABLE: vulnerable branch/take plus config indicators for IKEv1 + legacy clients + non-mandatory machine certs"
  exit 1
fi

fail_unknown "gateway version appears vulnerable, but config prerequisites could not be fully confirmed from exported configuration"

Sources

1. Check Point security blog advisory
2. NVD entry for the authoritative CVE
3. watchTowr technical analysis and DAG
4. Check Point IPS protection for public PoC
5. Rapid7 emergent threat response
6. Help Net Security PoC coverage
7. NHS England alert summarizing affected configurations