← Back to Feed CACHED · 2026-10-08 11:22:12 · CACHE_KEY CVE-2026-85102
CVE-2026-85102 · CWE-295 · Disclosed 2026-09-09

Check Point Quantum Security Gateway Pre-Auth RCE via VPN Certificate Trust Validation Bypass

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Your front door's lock accepts any key that looks vaguely key-shaped, and burglars already know

CVE-2026-85102 is a pre-authentication remote code execution vulnerability in the VPN certificate-handling code of Check Point Quantum Security Gateway and Spark Firewall products. The root cause lives in libcpcert.so: the function fwKeyHolder_imp::IsChainTrusted() calls CanonizeChain() but ignores its return value — when chain canonicalization fails, the function still returns TRUSTED. An attacker forges a leaf certificate using the target's own intermediate CA issuer DN, corrupts the ICA signature to deliberately trigger a canonicalization failure, and the gateway accepts the entire chain as valid. This completes IKE authentication without any credentials, yielding arbitrary code execution as root on the appliance. Affected versions span R81 (EoS) through R82.10 with Jumbo Hotfix Take 43 or below, R82 with Take 125 or below, R81.20 with Take 165 or below, and R81.10 with Take 189 or below, plus Spark Firewall builds prior to R82.00.10 Build 2325 and R81.10.17 Build 4968.

Check Point's own CRITICAL / 9.8 rating is entirely accurate — arguably conservative given the context. This is a textbook worst-case network-edge vulnerability: unauthenticated, zero-click, remotely exploitable over the internet against a device whose entire purpose is to sit on the perimeter with its VPN port exposed. There is no friction in this chain. The attack surface is the device's *raison d'être*. Active exploitation began three days after patch release, a public PoC exists on GitHub, and CISA added it to KEV with a 72-hour remediation deadline for federal agencies. If you run Check Point VPN and haven't patched, assume you are being probed right now.

"Pre-auth RCE on your perimeter firewall. Patch was yesterday. Active exploitation confirmed."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Identify exposed Check Point VPN endpoint

The attacker scans for internet-facing Check Point Security Gateways advertising IKEv1/IKEv2 on UDP 500/4500. These endpoints are exposed by design — they *are* the VPN concentrator. Fingerprinting tools like ike-scan or Shodan/FOFA queries return the target pool. ZoomEye shows at least ~1,852 fingerprinted instances; the real number is substantially higher given that Check Point holds significant enterprise firewall market share.
Conditions required:
  • Target runs Check Point Quantum Security Gateway or Spark Firewall with Site-to-Site or Remote Access VPN enabled
  • VPN port (UDP 500/4500) is reachable from the internet
Where this breaks in practice:
  • None — VPN endpoints are internet-facing by definition
Detection/coverage: Shodan/Censys/ZoomEye queries; network-level IKE scanning detected by GreyNoise or IDS rules for anomalous IKE SA_INIT volume
STEP 02

Extract intermediate CA certificate from the target

During a legitimate IKE negotiation attempt, the attacker harvests the gateway's intermediate Certificate Authority (ICA) certificate, which is sent in the clear or during IKE_AUTH exchange. The attacker needs only the ICA's Issuer Distinguished Name. This is passive reconnaissance that leaves minimal forensic trace.
Conditions required:
  • Attacker can initiate an IKE handshake with the target
Where this breaks in practice:
  • None — standard IKE behavior exposes the certificate chain
Detection/coverage: Anomalous IKE SA_INIT attempts from unknown sources; however, a single handshake blends into normal noise
STEP 03

Forge malicious certificate chain

Using the harvested ICA issuer DN, the attacker crafts a forged leaf certificate and deliberately corrupts the ICA signature. The PoC by aduli198 (GitHub: aduli198/CVE-2026-85102) automates this: CVE-2026-85102.py generates the malformed chain. The corrupted signature forces CanonizeChain() to fail, but because IsChainTrusted() ignores the return value, the entire chain is accepted as TRUSTED.
Conditions required:
  • Attacker has the ICA issuer DN from step 2
  • Target runs an unpatched version (pre-Take 44/126/166/190)
Where this breaks in practice:
  • None — the PoC is public and automated
Detection/coverage: Certificate subjects observed in the wild include CN=vpn,OU=users,O=global, CN=vpn-user,OU=users,O=global, and CN=vpnuser,OU=users,O=global; Check Point IPS signature may detect known PoC patterns
STEP 04

Complete IKE authentication and establish tunnel

The gateway processes the forged certificate, the trust check passes despite the invalid chain, and the attacker completes IKE Phase 1 authentication without valid credentials. The attacker now has an authenticated VPN session to the gateway itself. This is fully pre-authentication from the defender's perspective — no username, password, or MFA was ever evaluated.
Conditions required:
  • Steps 1-3 completed successfully
Where this breaks in practice:
  • None — this is the core of the vulnerability
Detection/coverage: Mobile Access logs showing certificate-based logins from unexpected IPs or with the known malicious CNs; anomalous VPN tunnel establishment without corresponding user-initiated connection
STEP 05

Achieve arbitrary code execution as root

Once the negotiation reaches a code path operating on attacker-controlled certificate data, execution flow is redirected. The attacker achieves arbitrary code execution on the Gaia OS underlying the gateway, running as root. The cp_postex.py helper in the PoC facilitates post-exploitation. At this point the attacker owns the perimeter firewall: they can intercept all traffic, harvest credentials, modify firewall rules, pivot to internal networks, and disable logging.
Conditions required:
  • Authenticated VPN session from step 4
Where this breaks in practice:
  • None
Detection/coverage: Anomalous processes on the gateway; unexpected outbound connections; modified firewall rulebase; Check Point Integrity Monitoring alerts; forensic analysis of /var/log/ and SmartConsole audit trail
03 · Compensating Control

1
CRITICAL 9.8→IGNORE 0.0
SEVERITY REDUCED
Apply the vendor patch immediately — Install Jumbo Hotfix R82.10 Take 44+, R82 Take 126+, R81.20 Take 166+, or R81.10 Take 190+ (or LivePatch Take 26 for faster deployment without reboot). This is the only definitive remediation. Per the noisgate mitigation SLA for CRITICAL, deploy within 3 days. Given active exploitation and KEV listing, deploy within hours — CISA's own deadline was 72 hours from 2026-09-22, already past.
2
CRITICAL 9.8→IGNORE 0.0
SEVERITY REDUCED
Disable VPN blade if not operationally required — If the gateway is used only as a firewall (no Site-to-Site or Remote Access VPN), disabling the VPN blade in SmartConsole removes the attack surface entirely. This eliminates the IKE listener on UDP 500/4500. Verify with enabled_blades in cpconfig. Deploy within 3 days per noisgate mitigation SLA for CRITICAL.
3
CRITICAL 9.8→HIGH 7.5
SEVERITY REDUCED
Restrict VPN peer IPs for Site-to-Site deployments — For gateways used exclusively for Site-to-Site VPN with known peer IPs, apply an upstream ACL or ISP-level filter to restrict UDP 500/4500 to only the known peer gateway addresses. This prevents arbitrary internet hosts from reaching the IKE listener. Does NOT help for Remote Access VPN deployments where clients connect from arbitrary IPs. Deploy within 3 days.
4
CRITICAL 9.8→CRITICAL 9.8
Monitor for known IoC certificate subjects — Configure SmartConsole log queries and SIEM alerts for certificate-based Mobile Access logins with subjects matching CN=vpn,OU=users,O=global, CN=vpn-user,OU=users,O=global, or CN=vpnuser,OU=users,O=global. Also alert on any VPN tunnel establishment from anonymization infrastructure (Tor exit nodes, known VPN provider IP ranges). This is detection, not prevention — it does not reduce exploitability but accelerates incident response.
5
CRITICAL 9.8→CRITICAL 9.0
Isolate gateway management plane — Ensure the gateway's management interface (HTTPS/18264, SSH) is not reachable from the internet and is restricted to a dedicated management VLAN. This limits post-exploitation lateral movement toward SmartCenter/Management Server, especially given the related CVE-2026-93616. Deploy within 3 days.
What doesn't work
  • MFA on VPN users — The vulnerability is pre-authentication; certificate validation fails *before* any user identity check, MFA challenge, or RADIUS/LDAP lookup is reached. MFA protects nothing here.
  • WAF or HTTP-layer inspection — This is an IKE/IPsec protocol-level flaw on UDP 500/4500, not an HTTP vulnerability. Web application firewalls do not inspect IKE traffic.
  • Check Point IPS blade alone — While Check Point may release IPS signatures for known PoC patterns, attackers can trivially modify certificate subjects and exploit structure to evade signature-based detection. IPS is a speed bump, not a fix.
  • Network segmentation behind the gateway — The gateway IS the segmentation boundary. Compromising it gives the attacker root on the device that enforces segmentation, rendering downstream zones moot.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationConfirmed active since 2026-09-12, three days post-patch. Check Point observed attacks against Spark customers globally, originating from anonymization infrastructure (VPNs, proxies). Certificate subjects used: CN=vpn, CN=vpn-user, CN=vpnuser (all under OU=users,O=global). Check Point warns more subjects may be in use.
CISA KEV StatusListed 2026-09-22 with a federal remediation deadline of 2026-09-25 (72 hours). BOD 22-01 binding on FCEB agencies. CISA Alert
Proof-of-ConceptPublic PoC available. GitHub repo aduli198/CVE-2026-85102 contains CVE-2026-85102.py (exploit) and cp_postex.py (post-exploitation). Also indexed on Sploitus. The PoC automates the full chain from ICA extraction through forged certificate generation to RCE.
EPSS0.07546 (7.55%) — top ~7th percentile of all CVEs for predicted exploitation probability within 30 days. Given confirmed exploitation, EPSS is trailing reality.
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — Network attack vector, low complexity, no privileges, no user interaction, full CIA impact. Every metric is worst-case. Score: 9.8.
Affected VersionsSecurity Gateway: R81 (EoS), R81.10 (EoS), R81.10.X, R81.20, R82, R82.00.X, R82.10. Spark Firewall: R82.00.10 (Build <2325), R81.10.17 (Build <4968). R82.20 is not affected.
Fixed VersionsJumbo Hotfix: R82.10 Take 44+, R82 Take 126+, R81.20 Take 166+, R81.10 Take 190+. Spark: R82.00.10 Build 2325+, R81.10.17 Build 4968+. LivePatch Take 26 for R81.20/R82/R82.10. Vendor advisory: sk1000117.
Exposure SurfaceZoomEye shows ~1,852 fingerprinted Check Point VPN instances; actual global deployment significantly higher. Check Point is a Gartner Magic Quadrant Leader for Hybrid Mesh Firewalls. VPN endpoints are internet-facing by design — 100% of affected deployments are reachable from the internet if VPN blade is enabled.
Disclosure Timeline2026-09-07: Initial disclosure by Check Point. 2026-09-09: Emergency patches released (sk1000117). 2026-09-10: Dutch NCSC alert. 2026-09-12: Active exploitation observed. 2026-09-22: CISA KEV listing. Discovered internally by Check Point.
Related VulnerabilitiesCVE-2026-93616: Pre-auth path traversal in Check Point Management Server web service, exploited as zero-day since 2026-07-23, also CVSS 9.8. Often chained or co-exploited with CVE-2026-85102 against combined Gateway+Management deployments.

Sources.

  1. Check Point Security Advisory (sk1000117)
  2. CISA KEV Alert — 2026-09-22
  3. Truesec — CVE-2026-85102 & CVE-2026-93616 Analysis
  4. BleepingComputer — Check Point VPN RCE Exploitation
  5. aduli198 PoC — GitHub
  6. Sploitus — Checkpoint Gaia Embedded PoC
  7. CyberStack — CVE-2026-85102 LivePatch Advisory
  8. Arctic Wolf — CVE-2026-85102 & CVE-2026-85103
05 · The Call

Final Verdict
= UNCHANGED to CRITICAL (9.8/10)

Why this verdict

  • Zero friction in attack chain: Every step from discovery to RCE requires zero authentication, zero user interaction, and zero special conditions. The VPN port is internet-facing by design. The PoC is public and automated. There is nothing gating exploitation.
  • Active exploitation + KEV listing: Confirmed in-the-wild exploitation since 2026-09-12, just three days after patch release. CISA's 72-hour remediation deadline for federal agencies underscores the urgency. Exploitation traffic originates from anonymization infrastructure, indicating organized threat actor activity.
  • Public weaponized PoC: The aduli198/CVE-2026-85102 repo provides a turnkey exploit that automates ICA extraction, certificate forgery, and post-exploitation. The barrier to entry for attackers is near zero.
  • Role multiplier: Check Point Quantum Security Gateway is canonically a network edge appliance — 100% of affected installations sit at the internet perimeter by definition. This is the high-value role catalog entry 'Network edge appliances: Check Point.' Compromising the gateway yields root on the appliance that controls all north-south traffic. Blast radius is network-wide to fleet-wide: the attacker can intercept credentials, modify firewall rules to permit lateral movement, disable logging, and pivot to every internal segment the gateway protects. In environments with centralized SmartCenter management, a compromised gateway can be leveraged to reach the management server (especially given the related CVE-2026-93616). The floor for this component is CRITICAL because ≥10% of installs — realistically ~100% — occupy the high-value perimeter role by definition.
  • CVSS vector has no downward adjustors: AV:N/AC:L/PR:N/UI:N — there is no prerequisite that narrows the reachable population or assumes a prior compromise stage. Every metric is already at worst-case.

Why not higher?

A 9.8 is effectively the ceiling for a Scope:Unchanged vulnerability under CVSS 3.1. The only way to reach 10.0 would be Scope:Changed, which would require demonstrating that the vulnerability enables compromise of resources *beyond* the vulnerable component's security authority. While gateway compromise certainly enables downstream pivoting, the CVSS 3.1 scoring convention treats the gateway itself as the impacted component. The 9.8 is the appropriate maximum.

Why not lower?

Every downgrade lever is already zeroed out. There is no authentication requirement, no user interaction, no unusual configuration prerequisite, no attacker positioning beyond 'can reach the internet.' The affected component is a perimeter device that is internet-facing by purpose, so 'requires network access' imposes no real narrowing. Active exploitation, a public PoC, KEV listing, and the canonical high-value role of a perimeter firewall/VPN gateway collectively make any downgrade indefensible. The deployment-role floor is CRITICAL and friction provides no basis to push below it.

06 · Verification

Crowdsourced verification payload.

Run this script on each Check Point gateway via SSH as the admin user, then enter Expert mode (expert). Invoke with: bash check_cve_2026_85102.sh. Requires Expert mode (root shell) to read version and hotfix data from fw ver and blade status.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/bin/bash
# check_cve_2026_85102.sh
# Checks whether a Check Point Gaia gateway is vulnerable to CVE-2026-85102
# Must be run in Expert mode (expert shell) on the gateway.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

echo "=== CVE-2026-85102 Check ==="
echo "Check Point Quantum Security Gateway / Spark - VPN Certificate Validation RCE"
echo ""

# Check if we're in expert mode
if [ "$(id -u)" -ne 0 ]; then
    echo "ERROR: Must run in Expert mode (run 'expert' first)."
    echo "UNKNOWN"
    exit 2
fi

# Get version info
FW_VER=$(fw ver 2>/dev/null || echo "")
if [ -z "$FW_VER" ]; then
    echo "ERROR: Cannot determine firewall version. Is this a Check Point gateway?"
    echo "UNKNOWN"
    exit 2
fi

echo "Detected version: $FW_VER"

# Check if VPN blade is enabled (if not, not exploitable)
VPN_ENABLED=$(cpprod_util FwIsVpn 2>/dev/null || echo "0")
if [ "$VPN_ENABLED" = "0" ]; then
    echo "INFO: VPN blade is not enabled. Attack surface not present."
    echo "PATCHED"
    exit 0
fi
echo "VPN blade: ENABLED (attack surface present)"

# Parse major version
MAJOR=""
if echo "$FW_VER" | grep -qi "R82.10"; then
    MAJOR="R82.10"
elif echo "$FW_VER" | grep -qi "R82.00\|R82 "; then
    MAJOR="R82"
elif echo "$FW_VER" | grep -qi "R81.20"; then
    MAJOR="R81.20"
elif echo "$FW_VER" | grep -qi "R81.10"; then
    MAJOR="R81.10"
elif echo "$FW_VER" | grep -qi "R81 \|R81$"; then
    MAJOR="R81"
elif echo "$FW_VER" | grep -qi "R80"; then
    MAJOR="R80"
elif echo "$FW_VER" | grep -qi "R82.20"; then
    echo "Version R82.20 detected — NOT AFFECTED per vendor advisory."
    echo "PATCHED"
    exit 0
fi

echo "Parsed major version: $MAJOR"

# Get installed hotfix take number
HOTFIX_TAKE=0
INSTALLED_JUMBO=$(cpinfo -y fw1 2>/dev/null | grep -i "Jumbo\|HOTFIX" | head -1 || echo "")
if [ -n "$INSTALLED_JUMBO" ]; then
    HOTFIX_TAKE=$(echo "$INSTALLED_JUMBO" | grep -oP 'Take\s*\K[0-9]+' || echo "0")
fi

# Also try clish approach
if [ "$HOTFIX_TAKE" = "0" ]; then
    HOTFIX_TAKE=$(clish -c "show installer status" 2>/dev/null | grep -oP 'Take\s*\K[0-9]+' | tail -1 || echo "0")
fi

echo "Detected Jumbo Hotfix Take: $HOTFIX_TAKE"
echo ""

# Evaluate against patched thresholds
case "$MAJOR" in
    R82.10)
        if [ "$HOTFIX_TAKE" -ge 44 ]; then
            echo "R82.10 Take $HOTFIX_TAKE >= Take 44. Fix applied."
            echo "PATCHED"
            exit 0
        else
            echo "R82.10 Take $HOTFIX_TAKE < Take 44. VULNERABLE."
            echo "VULNERABLE"
            exit 1
        fi
        ;;
    R82)
        if [ "$HOTFIX_TAKE" -ge 126 ]; then
            echo "R82 Take $HOTFIX_TAKE >= Take 126. Fix applied."
            echo "PATCHED"
            exit 0
        else
            echo "R82 Take $HOTFIX_TAKE < Take 126. VULNERABLE."
            echo "VULNERABLE"
            exit 1
        fi
        ;;
    R81.20)
        if [ "$HOTFIX_TAKE" -ge 166 ]; then
            echo "R81.20 Take $HOTFIX_TAKE >= Take 166. Fix applied."
            echo "PATCHED"
            exit 0
        else
            echo "R81.20 Take $HOTFIX_TAKE < Take 166. VULNERABLE."
            echo "VULNERABLE"
            exit 1
        fi
        ;;
    R81.10)
        if [ "$HOTFIX_TAKE" -ge 190 ]; then
            echo "R81.10 Take $HOTFIX_TAKE >= Take 190. Fix applied."
            echo "PATCHED"
            exit 0
        else
            echo "R81.10 Take $HOTFIX_TAKE < Take 190. VULNERABLE."
            echo "VULNERABLE"
            exit 1
        fi
        ;;
    R81|R80)
        echo "$MAJOR is End of Support and has NO patch available."
        echo "VULNERABLE — upgrade to a supported release immediately."
        echo "VULNERABLE"
        exit 1
        ;;
    *)
        echo "Unable to determine patch status for version: $MAJOR"
        echo "UNKNOWN"
        exit 2
        ;;
esac