A Certificate Can Make Your Check Point VPN Run an Attacker’s Code Before Login
Two certificate-processing flaws in Check Point VPN products can allow an unauthenticated attacker to execute code before a user logs in. Both carry a CVSS score of 9.8. Internet-facing gateways should be hotfixed immediately, while organisations still running end-of-support releases need to migrate rather than wait for a patch that is not coming.
The two vulnerabilities sit in the part of a VPN that must process network traffic before it can decide whether to trust the other party. That makes the usual access controls less helpful. An attacker does not need a valid account, a password or user interaction to reach the vulnerable code.
Check Point released emergency fixes on 9 September 2026. CERT-EU followed on 10 September with an advisory urging organisations to prioritise perimeter and internet-facing appliances.
BlackTree found no credible public exploit in its review on 11 September 2026, while the CVE records said exploitation had not been observed. Those facts reduce what defenders can claim, but they do not reduce the patching priority. Both flaws are remotely reachable, require no privileges and can have a total impact on confidentiality, integrity and availability.
Two flaws, two different certificate failures
CVE-2026-85102 is an improper certificate-validation vulnerability in the VPN negotiation flow of Check Point Quantum Security Gateway. A remote attacker can send certificate data that reaches the gateway before authentication and may execute arbitrary code. The vulnerable configuration is one using Remote Access VPN or Site-to-Site VPN.
CVE-2026-85103 is a heap-based buffer overflow in the ASN.1 decoder used for VPN certificates. It affects Quantum Security Gateway and Quantum Security Management. A specially formed certificate can corrupt heap memory and may allow remote code execution.
The distinction matters when building the asset list. CVE-2026-85102 is a gateway vulnerability tied to VPN negotiation. CVE-2026-85103 reaches both gateways and management systems through certificate decoding. An organisation that patches only the visible VPN gateway may therefore leave a management component exposed.
Check Point, as the assigning authority, rates both vulnerabilities 9.8 under CVSS 3.1. The published vectors describe network access, low attack complexity, no privileges and no user interaction.
Check the running hotfix take, not only the major release
For the currently supported Quantum product lines identified in Check Point's CVE records, the vulnerable and fixed levels are:
| Product | Affected release | Affected through | Fixed level |
|---|---|---|---|
| Quantum Security Gateway | R81.20 | Jumbo Hotfix Take 165 | Jumbo Hotfix Take 166 or later |
| Quantum Security Gateway | R82 | Jumbo Hotfix Take 125 | Jumbo Hotfix Take 126 or later |
| Quantum Security Gateway | R82.10 | Jumbo Hotfix Take 43 | Jumbo Hotfix Take 44 or later |
| Quantum Security Management | R81.20 | Jumbo Hotfix Take 165 | Jumbo Hotfix Take 166 or later |
| Quantum Security Management | R82 | Jumbo Hotfix Take 125 | Jumbo Hotfix Take 126 or later |
| Quantum Security Management | R82.10 | Jumbo Hotfix Take 43 | Jumbo Hotfix Take 44 or later |
Check Point also provides fixed Spark Firewall builds:
| Spark line | Fixed build |
|---|---|
| R81.10.X | R81.10.17 Build 4968 or later |
| R82.00.X | R82.00.10 Build 2325 or later |
R82.20 includes the correction. Organisations using Check Point LivePatch should verify that the relevant patch was installed successfully rather than assume automatic delivery completed.
CERT-EU lists R80, R80.10, R80.20, R80.30, R80.40, R81 and R81.10 as end of support. Check Point is not providing security fixes for those releases. R81.10.X and R82.00.X appliances need the applicable supported Spark build shown above.
The practical inventory question is therefore not simply, "Are we on R82?" It is, "Which appliance, which product role, which hotfix take or Spark build, and which VPN configuration is running now?"
Why a pre-authentication VPN flaw changes the response
A perimeter VPN appliance is designed to accept traffic from untrusted networks. When the vulnerable code runs before authentication, identity controls behind the appliance do not prevent an attacker from reaching it.
Successful exploitation could place attacker-controlled code on a device that terminates encrypted access and often has trusted paths into internal networks. On a management server, the same class of access could expose configuration, administrative workflows and the control plane used to manage other security gateways.
That does not mean every vulnerable system has been compromised. It means patching should not wait for a public exploit or a confirmed campaign. Once exploit code appears, defenders may have much less time to identify and upgrade every exposed appliance.
What defenders should do now
- Inventory every Check Point role. Include internet-facing gateways, centrally and locally managed Spark appliances, management servers, standby systems and disaster-recovery nodes.
- Record the exact take or build. A major-release label alone cannot establish whether the fix is present.
- Install the appropriate hotfix immediately. Use R81.20 Take 166, R82 Take 126, R82.10 Take 44, the fixed Spark builds or a later supported release.
- Verify LivePatch status. Confirm installation on each appliance and retain evidence for systems that failed or were offline during delivery.
- Migrate end-of-support systems. Network restrictions can reduce exposure while migration is completed, but they do not turn an unsupported release into a patched one.
- Restrict management access. Keep management interfaces off the public internet and limit them to dedicated administrative networks. This is defence in depth, particularly for CVE-2026-85103, not a replacement for the hotfix.
- Review for abnormal activity. Examine gateway and management logs, unexpected processes, administrative changes, new accounts, policy modifications and unexplained outbound connections. Preserve appliance evidence before rebuilding a system that appears suspicious.
- Test failover before the change window. A rushed perimeter update can become an availability incident if cluster state, standby versions or rollback plans are not understood.
A clean health check is not proof of absence
Check Point has not said these flaws are being exploited, and the CVE records currently mark exploitation as none observed. Defenders should preserve that distinction. Scanning, an unsuccessful exploit attempt and confirmed code execution are different events.
At the same time, a gateway that appears operational after an attack is not necessarily trustworthy. Security appliances can continue routing traffic while their configuration or operating environment has been altered. Any evidence of exploitation should therefore trigger incident response, not only patch management.
BlackTree has previously examined how a Check Point VPN bypass was followed by Qilin ransomware and how WatchGuard VPN handshakes exposed remote-code-execution paths. The lesson is consistent: the appliance that controls remote access is itself an internet-facing software system, and its pre-authentication parsing code belongs in the emergency patch queue.
For these Check Point flaws, the decision is unusually clear. Supported systems have fixes. Unsupported systems have a migration problem. Waiting for exploitation evidence only gives an attacker more time to turn a published trust-boundary failure into an operational tool.
Sources
- Check Point sk1000117: CVE-2026-85102, vendor advisory dated 9 September 2026.
- Check Point sk1000118: CVE-2026-85103, vendor advisory dated 9 September 2026.
- CERT-EU Security Advisory 2026-012, released 10 September 2026 at 08:20:06 UTC.
- CVE Program record for CVE-2026-85102, published 9 September 2026 at 13:00:31 UTC.
- CVE Program record for CVE-2026-85103, published 9 September 2026 at 13:00:42 UTC.
- CERT Polska remediation summary, published 10 September 2026, no time provided.
