Practical Linux guidance for safer servers and self-hosted systems.Linux • Security • Self-hosting • Practical tools
Secure Remote Access

CVE-2026-85102: What Check Point VPN Operators Need to Know

CVE-2026-85102 is a critical Check Point VPN vulnerability involving improper certificate-data validation during VPN negotiation. Check Point says an unauthenticated remote attacker may be able to execute arbitrary code on an affected Security Gateway, and its September 20 update says the issue was actively exploited on Spark Firewalls as of September 12, 2026. The documented scope is Check Point Security Gateway and specified Spark Firewall VPN products, not Linux VPN software in general. [1][2]

This is a Track A explainer: it maps the advisory’s trust boundary and fixed-version information, but it does not provide patch commands, firewall changes, or VPN configuration steps.

Which Check Point deployments are in scope?

Check Point names Security Gateway and Spark Firewall deployments using Site-to-Site VPN or Remote Access VPN. The advisory lists affected R81.20, R82, and R82.10 branches, along with older end-of-support releases and branch variants. It lists R82.20 as not affected. [1]

The important distinction is not simply “does this organisation use a VPN?” It is whether the deployment matches the affected Check Point product and version scope in the current vendor advisory.

Why certificate authentication matters for Site-to-Site VPN

For Site-to-Site VPN, Check Point says the issue affects gateways that use or allow certificate-based authentication. It specifically notes that Dynamic IP Gateway and Large Scale VPN communities enable certificate authentication, while gateways participating only in encryption communities authenticated with a pre-shared key are not vulnerable to this condition. [1]

That distinction is a trust-boundary detail, not a general rule that pre-shared keys make a VPN safe. It describes the applicability of this specific certificate-validation issue as documented by Check Point.

Remote Access VPN is also named in the advisory’s affected product and deployment scope. Organisations should therefore avoid reducing the review to a single Site-to-Site configuration question.

What does active exploitation change?

Check Point’s advisory states that the vulnerability was actively exploited on Spark Firewalls as of September 12, 2026. That is a vendor statement about observed exploitation, not proof that every Check Point deployment was compromised. It does make the product, version, VPN-mode, and exposure review time-sensitive. [1]

The advisory also provides log-review indicators for anomalous certificate-based Mobile Access logins and suspicious certificate subjects. Those indicators should be interpreted through the current vendor advisory and the organisation’s incident-response process; this article does not turn them into an unverified forensic procedure.

What fixed baselines does Check Point publish?

The current Check Point advisory lists LivePatch Take 26 for R82.10, R82, and R81.20, plus branch-specific Jumbo Hotfix Accumulator and Spark Firewall build baselines. It lists fixes beginning at R82.10 Take 44, R82 Take 126, R81.20 Take 166, R81.10 Take 190, Spark R82.00.10 Build 2325, and Spark R81.10.17 Build 4968. [1]

The CVE record independently lists affected thresholds of R82.10 Jumbo Hotfix Take 43 or below, R82 Take 125 or below, and R81.20 Take 165 or below. These records should be read together with the vendor advisory because Check Point also documents an offline-LivePatch caveat for customers on older hotfix takes. [1][2]

“Install the latest update” is not a sufficiently precise conclusion for a security brief when the vendor publishes branch-specific take and build numbers. The authoritative source for the applicable fix path remains Check Point’s current advisory and linked procedure.

What this does—and does not—say about Linux VPNs

CVE-2026-85102 is relevant to Linux operators when Check Point equipment is part of their remote-access or site-to-site boundary. It does not establish that WireGuard, OpenVPN, strongSwan, Tailscale, or every Linux host running a VPN is affected.

For a broader access decision, start with the secure remote access guide, which separates private administration from public services. For a general prioritisation model, see the CISA KEV triage guide. This advisory should be treated as a vendor-specific trust-boundary review, not as a reason to rewrite unrelated Linux VPN infrastructure.

A calm review sequence for small organisations

A useful review starts with four questions:

  1. Do we operate Check Point Security Gateway or Spark Firewall products named by the advisory?
  2. Does the deployment use Remote Access VPN or certificate-authenticated Site-to-Site VPN?
  3. Which exact product branch, hotfix take, or Spark build is recorded in the vendor’s affected/fixed mapping?
  4. Is the current state covered by the vendor’s documented fix path, including the offline-LivePatch caveat and any exploitation indicators relevant to incident response?

Those questions identify the decision boundary without turning a source-backed brief into an unverified change procedure. Any update, mitigation, firewall, VPN configuration, or incident-response action must follow the current Check Point instructions and the organisation’s own recovery and access controls.

Sources

  1. Check Point SK1000117: CVE-2026-85102, last modified 24 September 2026.
  2. CVE-2026-85102, updated 9 September 2026.
  3. CISA Known Exploited Vulnerabilities Catalog, consulted 6 October 2026 for catalog context; no CVE-specific status was asserted here without a direct row match.