Check Point has released emergency security updates for two critical VPN vulnerabilities that deserve the same treatment as any other internet-facing perimeter incident. CVE-2026-85102 and CVE-2026-85103 are both rated CVSS 9.8. According to CERT-EU's summary of the vendor advisories, each can allow an unauthenticated remote attacker to execute arbitrary code on an affected appliance.
The urgency is not a claim that exploitation has been confirmed. The sources reviewed for this article do not establish that. The urgency comes from the affected surface: a VPN gateway is deliberately reachable from outside the organisation, is often trusted by internal systems, and frequently holds credentials or routes that matter far beyond the appliance itself. A critical pre-authentication remote-code-execution path on that boundary is an emergency patching problem even before a public exploitation report arrives.
Two certificate-processing failures, not one generic VPN bug
CVE-2026-85102 is an improper certificate-data validation issue in the VPN negotiation flow of Check Point Security Gateway. CERT-EU says it affects deployments using either Remote Access VPN or Site-to-Site VPN. In practical terms, the first question for an administrator is not whether a gateway has a public web interface; it is whether these VPN capabilities are configured and reachable.
CVE-2026-85103 is distinct: a heap-overflow issue in VPN certificate ASN.1 decoding. It affects Check Point Security Gateway and, unlike the first vulnerability, can also affect the Security Management Server in the relevant VPN configurations. Treating both CVEs as one undifferentiated bulletin risks missing the management-plane implication of the second flaw.
The published affected-product list includes Security Gateway releases R81.10.X, R81.20, R82, R82.00.X and R82.10, along with listed Security Management Server versions and centrally or locally managed Spark Firewall versions. It also includes older R80 through R81.10 lines that are end of support. End-of-support is not a footnote here: an appliance with no supported remediation path turns a patch ticket into a replacement or containment decision.
Start with exposure, then patch
Do not begin with a broad vulnerability-scanner result. Begin with an authoritative inventory of Check Point gateways, management servers and Spark appliances, then identify which ones have Remote Access VPN or Site-to-Site VPN enabled. Rank systems exposed to the internet first, followed by gateways reachable from partner networks or other untrusted segments.
- Identify the affected configuration. Confirm product family, software release and whether the relevant VPN service is enabled. Record the public address, owning team and change window.
- Apply the vendor hotfix. Use the remediation and compatibility guidance in Check Point's own advisories rather than guessing a target build from a third-party list. Validate the appliance returns to service and that the VPN negotiation path still works as designed.
- Restrict the management plane. Management interfaces should not be broadly internet reachable. Limit administration to approved networks and identities, and separate administrative access from ordinary remote-user VPN traffic.
- Review evidence around the exposure window. Preserve and inspect gateway, VPN and management logs for unusual negotiation failures, unexpected administrative access, configuration changes, new accounts or altered logging destinations.
Do not turn every patch into an unsupported breach claim
There is a useful distinction between urgent remediation and an incident declaration. Patch immediately because the documented impact is unauthenticated remote code execution on a perimeter service. Escalate into credential rotation, gateway rebuilds or a full incident response when telemetry, vendor guidance or other evidence supports a compromise hypothesis. That sequence avoids both complacency and performative panic.
For teams that manage these devices centrally, this is also a test of the emergency-change process. A critical advisory should not require a new meeting to decide who may patch an internet-facing VPN appliance. Pre-authorise the condition, identify deputies and make the retrospective documentation requirement explicit. The technical fix may be a hotfix; the operational control is the ability to deploy it before the next disclosure becomes an exploitation report.
What to do today
Find every affected Check Point deployment, flag the systems with Remote Access VPN or Site-to-Site VPN, and prioritise perimeter-facing appliances. Apply the vendor's available hotfixes, keep the evidence needed to investigate later, and make a separate plan for unsupported releases. The risk is not abstract: certificate handling sits directly in a trust-establishment path, which is precisely where an unauthenticated flaw has the least room for error.
