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.
5 steps from start to impact.
Identify exposed Check Point VPN endpoint
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.- 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
- None — VPN endpoints are internet-facing by definition
Extract intermediate CA certificate from the target
- Attacker can initiate an IKE handshake with the target
- None — standard IKE behavior exposes the certificate chain
Forge malicious certificate chain
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.- Attacker has the ICA issuer DN from step 2
- Target runs an unpatched version (pre-Take 44/126/166/190)
- None — the PoC is public and automated
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 patternsComplete IKE authentication and establish tunnel
- Steps 1-3 completed successfully
- None — this is the core of the vulnerability
Achieve arbitrary code execution as root
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.- Authenticated VPN session from step 4
- None
/var/log/ and SmartConsole audit trailenabled_blades in cpconfig. Deploy within 3 days per noisgate mitigation SLA for CRITICAL.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.- 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.
The supporting signals.
| In-the-Wild Exploitation | Confirmed 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 Status | Listed 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-Concept | Public 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. |
| EPSS | 0.07546 (7.55%) — top ~7th percentile of all CVEs for predicted exploitation probability within 30 days. Given confirmed exploitation, EPSS is trailing reality. |
| CVSS Vector | CVSS: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 Versions | Security 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 Versions | Jumbo 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 Surface | ZoomEye 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 Timeline | 2026-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 Vulnerabilities | CVE-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.
- Check Point Security Advisory (sk1000117)
- CISA KEV Alert — 2026-09-22
- Truesec — CVE-2026-85102 & CVE-2026-93616 Analysis
- BleepingComputer — Check Point VPN RCE Exploitation
- aduli198 PoC — GitHub
- Sploitus — Checkpoint Gaia Embedded PoC
- CyberStack — CVE-2026-85102 LivePatch Advisory
- Arctic Wolf — CVE-2026-85102 & CVE-2026-85103
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-85102repo 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.
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.
#!/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