Check Point CVE-2026-85102 and 85103: VPN Flaws

What do CVE-2026-85102 and CVE-2026-85103 allow?

CVE-2026-85102: a failure to validate certificate trust during VPN negotiation can allow an unauthenticated remote attacker to run arbitrary code on the gateway (CVSS v3.1 9.8).

CVE-2026-85103: a heap overflow while decoding the ASN.1 structure of a VPN certificate can allow arbitrary code execution on Quantum Security Management and Quantum Security Gateway systems (CVSS v3.1 9.8). According to a Check Point employee quoted by The Hacker News, the defect could in theory be triggered without the VPN blade enabled, as long as VPN certificates are present. Check Point has not detailed the "specific conditions" required.

Both flaws trigger during certificate processing, an attacker-controlled input in VPN flows. Check Point discovered them internally and assigned the identifiers and scores itself.

Which versions are affected and which fixes apply?

Per the CVE records: R82.10 with Jumbo Hotfix up to Take 43, R82 up to Take 125 and R81.20 up to Take 165. According to BleepingComputer, the fixes are:

• Live Patch (Take 24) for R81.20, R82 and R82.10, rolled out automatically since September 9 for customers who use it;
• Jumbo Hotfix: R82.10 Take 44 or later, R82 Take 126 or later, R81.20 Take 166 or later;
• Spark: R82.00.10 build 2325 or later, R81.10.17 build 4968 or later.

R82.20 is not affected. End-of-support branches (R80 to R80.40, R81, R81.10) are exposed without a fix; customers reported that no fix or Live Patch exists for R81.10, only a mitigation judged vague. The advisories are sk1000117 and sk1000118.

What is the exploitation status?

On September 9, Check Point said it had no sign of exploitation and published no indicators of compromise. The Dutch NCSC then warned it expected exploitation attempts soon, with no public proof of concept at that date. NVD shows CVE-2026-85102 was added to CISA's KEV on September 22, 2026, which signals observed exploitation. Earlier Check Point VPN flaws (CVE-2026-50751 in June, CVE-2026-16232 in July) had also been listed in the KEV.

How do you verify and detect?

1. Read the effective version of each gateway and console (the Jumbo Hotfix level actually installed, not the planned one), including Spark lines and management servers.
2. Check Live Patch: the advisory states it covers only R81.20, R82 and R82.10 and not every configuration.
3. Inventory VPN certificates present on devices, including gateways whose VPN seems inactive.
4. Log and alert on VPN negotiation failures and on connection attempts with malformed certificates.
5. Look for signs of compromise on gateways: unexpected processes, new administrator accounts, unusual outbound connections.

How do you fix it?

Apply the fix by the fastest route available: Live Patch or the latest Jumbo Hotfix. For branches with no fix, reduce exposure: for the site-to-site VPN function, restrict rules to trusted addresses, limit allowed sources and plan migration to a supported branch. After any exposure of a gateway before the fix, rotate the secrets that pass through it (pre-shared keys, administration accounts, certificates).

What changes when an AI agent has access through a VPN or gateway?

Many agents and MCP tools run behind the VPN with the implicit assumption that "the internal network is trusted": no authentication on the tool server, long-lived tokens, access to internal databases and APIs. A compromised gateway makes that assumption false in an instant: the attacker lands on the same network as the agent's tools and can call them directly, or alter what the agent reads (OWASP LLM01, LLM06). See MCP security.

Two complementary effects. Certificate authentication extends to machines and agents (mutual TLS between an agent and its tools): a certificate-handling defect is therefore a risk for that layer. And dependency: an agent whose access goes through a gateway that is unavailable or being patched fails unpredictably; test the degraded mode. Useful controls: authentication specific to each tool whatever the network, short-lived tokens, segmentation behind the gateway, logging of tool calls and human approval of sensitive actions. See AI agent security and the article on Citrix NetScaler.

How do you reduce risk when the fix cannot be applied right away?

Limit the allowed sources on VPN rules to trusted addresses, remove unused VPN services, enable detailed logging of negotiations and watch for unexpected restarts of VPN processes. Prepare the fix's rollback, document devices on uncovered branches with a migration date and assign an owner to each. A partial mitigation applied today beats a perfect fix applied in three weeks. Tell the teams that run agents behind the gateway about the maintenance window too, so a gateway restart is not mistaken for an agent failure and worked around unsafely.

How do you test an agent against Check Point CVE-2026-85102 and 85103?

An agent red team starts from the assumption of an attacker already on the internal network and checks what the agent's tools accept without authentication, which tokens are reusable and what a hijacked instruction can reach. The Agent Red Team Express (1,900 euros, 5 days) looks at what an agent behind a vulnerable Check Point VPN can reach. The method details the approach.

What is the lesson?

VPN gateways and firewalls are exposed by function and process unauthenticated input: their patch cycle must be the shortest in the estate, and the architecture must assume they can be compromised, with segmentation, authentication of internal services and monitoring of the accounts that pass through them.