A heap-based buffer overflow in VPN certificate ASN.1 decoding may

CVE-2026-85103 is a heap-based buffer overflow in the ASN.1 certificate-parsing code of Check Point's VPN stack. When a Quantum Security Gateway or Security Management Server processes a maliciously crafted X.509 certificate during VPN negotiation, the overflow allows an unauthenticated remote attacker to achieve arbitrary code execution on the appliance. Affected releases are R81.20 (Jumbo Hotfix Take 165 and below), R82 (JHF Take 125 and below), and R82.10 (JHF Take 43 and below). End-of-support versions R80 through R81.10 are also vulnerable. R82.20 is unaffected. Spark Firewall models share the same vulnerable code path.

Check Point rated this CVSS 9.8 CRITICAL, and for once, the vendor score is dead accurate. There is zero friction in the attack path: the VPN listener *must* be internet-facing for the product to function, ASN.1 parsing fires before any authentication occurs, and the attacker needs nothing more than a TCP connection to the VPN port. This is a perimeter appliance RCE with no prerequisites — the 9.8 is earned.

Why this verdict

• Unauthenticated pre-auth RCE: The overflow triggers during VPN certificate parsing before any authentication occurs. The attacker needs nothing but a TCP connection to the VPN port — no credentials, no user interaction, no special configuration.
• Role multiplier: Check Point Quantum Security Gateway is *canonically* a network edge appliance. 100% of deployments sit at the internet perimeter. Compromise yields root on the firewall itself — the blast radius is fleet-scale (all traffic, all VPN users, direct L3 path to every internal subnet). If the Management Server is co-located or also vulnerable, the attacker controls the entire Check Point policy infrastructure. This alone sets the verdict floor at CRITICAL.
• Zero effective friction: Unlike vulns that require internal network access or authentication, this one targets a service that *must* be internet-exposed. There are no prerequisites that narrow the reachable population. ASN.1 parsing is deterministic and occurs in every VPN handshake.
• Large attack surface: 20,000–45,000 internet-facing Check Point devices historically indexed. Spark Firewalls in SMB deployments share the same code path, broadening the victim pool.
• Historical precedent: Check Point VPN vulns (CVE-2024-24919, CVE-2026-50751) were weaponized and KEV-listed rapidly. Ransomware affiliates have specifically targeted Check Point appliances. The time-to-exploit for this class of bug is measured in days to weeks, not months.

Why not higher?

There is no severity above CRITICAL. CVSS 9.8 is already the maximum for Scope:Unchanged. The only reason this isn't 10.0 is that Check Point scores it as Scope:Unchanged (compromise of the gateway doesn't automatically change the security scope of other components in the CVSS model, even though operationally it clearly does).

Why not lower?

Every downgrade factor is absent here. There are no authentication requirements, no unusual configuration prerequisites, no limited version range, and no friction from deployment topology — the VPN port is exposed by design. The affected component is the perimeter firewall itself, which is the highest-value network role. No PoC is the only temporal mitigant, and that is a countdown timer, not a structural defense. Check Point appliances have been targeted by ransomware groups (cf. CVE-2024-24919 campaign) and this bug class (pre-auth heap overflow on a network appliance) is the #1 priority for exploit developers.

1. Enable LivePatch immediately on all Check Point gateways — Check Point's LivePatch service auto-deploys the fix without a reboot or policy install. If it's not already enabled, this is the fastest path to remediation — deploy within the 3-day noisgate mitigation SLA. Verify via cpinfo -y all or SmartConsole that the LivePatch took.
2. Install the Jumbo Hotfix Accumulator for your branch — Apply R82.10 JHF Take 44+, R82 JHF Take 126+, or R81.20 JHF Take 166+ during your next maintenance window. LivePatch buys time, but the full JHF is the durable fix. Schedule within 3 days.
3. Update IPS signatures and enable strict SSL inspection on VPN handshakes — Ensure the Check Point IPS blade is active and signature-current. Deploy any vendor-provided IPS protection for sk1000118. This may catch unsophisticated exploit attempts, though a skilled attacker can likely evade signature-based detection.
4. Monitor gateway process trees and crash logs — Set up alerts for unexpected child processes from VPN daemons (vpnd, sslvpn), daemon crashes, or core dumps. These are precursor indicators of exploitation attempts. Feed gateway logs to your SIEM with a 15-minute alert SLA.
5. Audit and decommission end-of-support gateways (R80–R81.10) — These versions will not receive a patch. If you have R80, R81, or R81.10 appliances still in production, they are permanently vulnerable. Begin emergency migration to R81.20+ or R82.x within the 3-day window, or isolate them behind a separate filtering device.

Run this script on each Check Point gateway via SSH or console as admin (or expert mode). Example: ssh [email protected] 'bash -s' < check_cve_2026_85103.sh. Requires cpinfo and fw ver commands available in Gaia OS.

#!/bin/bash
# check_cve_2026_85103.sh
# Checks whether a Check Point Gaia gateway is vulnerable to CVE-2026-85103
# Run on the gateway itself in expert mode or via SSH as admin.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

RESULT="UNKNOWN"

# Get the installed version and JHF take
VERSION=$(fw ver 2>/dev/null | grep -oP 'R\d+\.?\d*' | head -1)
JHF_TAKE=$(cpinfo -y all 2>/dev/null | grep -i 'Jumbo.*Take' | grep -oP '\d+' | tail -1)

if [ -z "$VERSION" ]; then
  echo "UNKNOWN - Could not determine Check Point version."
  exit 2
fi

echo "Detected version: $VERSION, JHF Take: ${JHF_TAKE:-none}"

case "$VERSION" in
  R82.20|R83*)
    RESULT="PATCHED"
    ;;
  R82.10)
    if [ -n "$JHF_TAKE" ] && [ "$JHF_TAKE" -ge 44 ]; then
      RESULT="PATCHED"
    else
      RESULT="VULNERABLE"
    fi
    ;;
  R82)
    if [ -n "$JHF_TAKE" ] && [ "$JHF_TAKE" -ge 126 ]; then
      RESULT="PATCHED"
    else
      RESULT="VULNERABLE"
    fi
    ;;
  R81.20)
    if [ -n "$JHF_TAKE" ] && [ "$JHF_TAKE" -ge 166 ]; then
      RESULT="PATCHED"
    else
      RESULT="VULNERABLE"
    fi
    ;;
  R81.10|R81|R80.40|R80.30|R80.20|R80)
    RESULT="VULNERABLE"
    echo "WARNING: End-of-support version detected. No patch available."
    ;;
  *)
    RESULT="UNKNOWN"
    ;;
esac

# Also check LivePatch status
LIVEPATCH=$(cpinfo -y all 2>/dev/null | grep -i 'livepatch\|LP-' | head -3)
if [ -n "$LIVEPATCH" ]; then
  echo "LivePatch info: $LIVEPATCH"
fi

echo "$RESULT"
case "$RESULT" in
  PATCHED)    exit 0 ;;
  VULNERABLE) exit 1 ;;
  *)          exit 2 ;;
esac

Sources

1. SecurityOnline – CVE-2026-85102 & 85103: Check Point VPN Flaws
2. THREATINT – CVE-2026-85103
3. OffSeq Threat Radar – CVE-2026-85103
4. Check Point Advisory sk1000118 (referenced)
5. Red Hat Advisory RHSA-2026:25237
6. The Record – Check Point Devices Vulnerable
7. runZero – Check Point Device Identification
8. CVE.org – CVE-2026-85103