CSIPE

Published

- 21 min read

The Check Point VPN Patch Needs Proof on Every Gateway

Network Security Incident Response Vulnerabilities VPN

Books by the author

Compare all 5

As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog.

A company VPN gateway sits at an awkward boundary. It has to accept traffic from the public internet before it knows who is on the other end, then decide whether that stranger should receive a trusted path into the organisation. The certificate parser is part of that first conversation. If the parser can be made to run somebody else’s code, the login screen is beside the point.

Check Point put that problem in front of customers on 9 September 2026. The company released fixes for two vulnerabilities in the way several firewall and management products process VPN certificates. CVE-2026-85102 is an improper certificate-validation flaw during VPN negotiation. CVE-2026-85103 is a heap overflow in the code that decodes a certificate’s ASN.1 structure. Check Point rates both at 9.8 out of 10 and says each can permit remote code execution without authentication under the documented conditions (Check Point 85102, Check Point 85103).

The Netherlands’ National Cyber Security Centre raised the priority on 10 September. It said no public proof-of-concept or exploit code had been reported, but assessed both the likelihood and possible impact of abuse as high and expected attempts soon (NCSC-NL alert). Check Point, meanwhile, said it had no indication of exploitation when it disclosed the flaws. Those statements are compatible. One describes what is known to have happened; the other describes a defender’s forecast.

The right response is urgent without being theatrical. Find every affected appliance, reduce exposure where the vendor’s mitigation fits, install the supported fix, and prove that protection is active on each running node. Then preserve enough evidence to answer the narrower local question: did anyone send suspicious VPN traffic to this gateway before it was fixed? A dashboard that says “deployment complete” is a starting point. The receipt lives on the gateways.

What was fixed on 9 September

The two flaws share a date, a severity score, and a certificate-processing theme, but they do not have identical scope. Treating them as one generic “VPN bug” makes it easier to miss a management server or misapply a mitigation. The product inventory has to preserve the distinction.

CVE-2026-85102 happens during VPN negotiation. Check Point says improper validation of certificate data may let an unauthenticated remote attacker execute arbitrary code on a Security Gateway. The affected product description covers Security Gateway and Check Point Spark Firewall systems using Site-to-Site VPN or Remote Access VPN. In plain English, a system can begin parsing material supplied during the connection setup before it has established that the caller is trusted.

CVE-2026-85103 sits in the ASN.1 decoder used for VPN certificates. ASN.1 is a standard way of describing structured data, and certificates commonly use an ASN.1-based encoding. A heap overflow means the decoder can write beyond the memory area reserved for part of that input. Check Point says this flaw may allow remote code execution on Security Gateway and Security Management Server products, and its affected-product list also includes Spark Firewall (Check Point 85103).

That management-server reach matters. The gateway is the obvious perimeter system because it receives VPN negotiations from outside. The management server is where operators define policy and administer gateways. Check Point’s public advisory names it for CVE-2026-85103, so a response that inventories only boxes labelled “VPN gateway” is incomplete. CERT-EU likewise identifies Security Gateway, Security Management Server, and Spark Firewall among the affected product families (CERT-EU).

Check Point lists R81.20, R82, R82.10, R81.10.x, and R82.00.x as affected, along with the end-of-support R80, R80.10, R80.20, R80.30, R80.40, R81, and R81.10 branches. R82.20 is listed as unaffected. The presence of old branches in an affected list does not promise that each old branch has a supported patch route. It tells an operator that old software remains in the exposure discussion.

For supported mainline branches, Check Point offers two repair paths. Its urgent LivePatch bundle is Take 24 for R81.20, R82, and R82.10. The fixes also appear in Jumbo Hotfix Accumulator Take 166 or later for R81.20, Take 126 or later for R82, and Take 44 or later for R82.10. Spark fixes begin with R81.10.17 Build 4968 and R82.00.10 Build 2325, according to the vendor advisories.

CERT-EU called the updates emergency security updates and recommended prioritising internet-facing and perimeter appliances. NCSC-NL advised organisations to install them as quickly as possible. Neither recommendation requires a confirmed victim list. A remotely reachable, pre-authentication path on a boundary appliance deserves a short repair clock even while exploitation remains unconfirmed.

Why authentication cannot save a pre-authentication parser

A VPN connection starts before a user receives access to private systems. The gateway must listen on the network, interpret enough of the protocol to understand the request, examine cryptographic material, and decide what comes next. Some of that work necessarily happens before the system can accept or reject an identity.

Picture a secure office with a reception desk inside the front door. Visitors must present a badge, but the receptionist has to take the badge and read it before deciding whether it is genuine. A flaw in the badge reader can be reached by a visitor who never had a valid badge. Strong employee authentication does not repair the reader.

CVE-2026-85102 concerns trust validation during that early negotiation. Certificate validation normally asks whether a presented certificate belongs to a chain the system trusts and whether it is acceptable for this purpose. If the implementation handles that decision incorrectly, the security failure occurs inside the process meant to establish trust. “We require certificates” is therefore not a complete answer. The vulnerable operation is processing the certificate.

CVE-2026-85103 concerns memory safety while decoding certificate structure. ASN.1 can represent nested values, lengths, identifiers, and other fields. A safe decoder has to reject malformed sizes and structures before they make memory operations exceed their bounds. A heap overflow means crafted input may corrupt memory and alter the program’s behaviour. The defensive conclusion does not require publishing a working exploit: untrusted certificate data reaches a decoder with a critical memory-safety flaw.

The two mechanisms explain the 9.8 scores and the emphasis on unauthenticated remote access. They also explain why ordinary account controls are not enough. Multi-factor authentication protects the later decision to create a user session. Password rotation protects credentials. Neither changes the vulnerable certificate-processing code that runs before a normal user proves who they are.

Network position still matters. A service that cannot receive the relevant traffic from an attacker offers less opportunity than one exposed to the public internet. That is why Check Point’s temporary mitigation for Site-to-Site VPN narrows UDP ports 500 and 4500 to known peer addresses. The control reduces who can start the relevant conversation. It does not rewrite the parser.

Remote Access VPN is harder to narrow by peer address because legitimate users connect from changing networks. A rule that accepts only fixed partner gateways can work for a site-to-site tunnel, where each end is known. Applying the same idea to travelling staff may break the service or simply be impossible. The vendor advisory also says this mitigation does not apply to locally managed Spark Firewall appliances.

That leaves a useful hierarchy. Install the fix wherever a supported repair exists. Use the vendor’s network restriction as temporary risk reduction where the deployment model permits it. Do not rename a workaround as a permanent patch, and do not improvise low-level policy changes from a news summary on a production perimeter device.

Automatic protection still needs a local receipt

Check Point says customers who enabled automatic installation of Check Point LivePatch will receive the protection automatically. That is valuable. A centrally delivered repair shortens the time between publication and protection, particularly across a large fleet. It also creates a tempting operational mistake: equating eligibility for automatic delivery with proof that every node is protected.

A fleet is rarely as uniform as its dashboard. One cluster member may have missed a maintenance event. A branch appliance may have lost contact with the update service. A standby node may be powered down during the rollout and return later. A support entitlement, proxy rule, disk condition, or local exception may make one device differ from its neighbours. The repair is real only where the running process has received it.

The vendor provides a concrete way to check. On a Security Gateway or ClusterXL member, Check Point says to run cpinfo -y CPupdates in Expert mode and confirm the urgent security update bundle at Take 24. It also says cplp list should show protected certificate-related processes against CVE-2026-85102 and CVE-2026-85103. Scalable Platform operators use g_all cplp list for the corresponding fleet view (Check Point 85102).

The output is more useful than a green orchestration job because it answers a question on the target. Did this node install the expected bundle, and does the LivePatch subsystem report protection for the named vulnerabilities? Save the result with the hostname and collection time. A generic success counter cannot tell the next engineer which member was checked.

Clustered systems make this discipline especially important. Traffic may move to a standby member during failover, maintenance, or an unrelated fault. If verification covers only the active node, the unverified member can become the public boundary later. Query every member. Where an orchestrator fans out the command, keep the per-node result rather than only the aggregate exit status.

The Jumbo Hotfix route needs a receipt too. Record the installed take on each relevant system and compare it with the vendor’s fixed floor. Verify that services returned, policy installation works, expected tunnels establish, and management communication remains healthy. A successful package transaction proves that an installer finished. It does not prove that the intended build is running everywhere or that the service recovered correctly.

Spark appliances have build numbers rather than the same Jumbo take sequence. Check the running build against the vendor’s stated fixed versions and confirm whether the appliance is centrally or locally managed. That detail affects both how the update arrives and whether the published Site-to-Site mitigation is applicable.

End-of-support branches need a decision, not hopeful arithmetic. Check Point marks R80 through R81.10 main branches as end of support in these advisories. If an appliance remains on one of them, the operator should contact Check Point or the responsible service provider for the supported migration and remediation path. Installing a current fix number intended for another branch is not a safe shortcut.

A useful coverage table can remain small. Give each device one row with its owner, role, management model, software branch, current take or build, VPN mode, public reachability, chosen repair, verification result, and evidence link. The table should make blanks uncomfortable. “Unknown” is an honest state that somebody can own; an empty cell disappears into the meeting.

The receipt changes the incident conversation. Instead of “we pushed the patch,” the team can say that 18 of 18 gateways and two management servers report the expected protection, that each cluster member was checked, and that the only retired R81.10 appliance was isolated pending replacement. That statement is testable. It can survive the next shift change.

Forecast, observation, and local evidence are different things

Security reporting often collapses three claims into one dramatic sentence: a vulnerability can be exploited, defenders expect exploitation, and attackers are exploiting it. Those claims carry different evidence. Keeping them separate produces better decisions and more credible incident notes.

As of 13 September 2026, Check Point’s position in the public reporting was that it had no indication the two September flaws had been exploited. The company said it found the issues internally. NCSC-NL said on 10 September that it expected attempts at broad abuse soon, while noting that no public proof-of-concept or exploit code had been reported. Independent reporting captured both positions (The Hacker News).

A forecast from a national cyber authority deserves attention, particularly for flaws exposed at network boundaries. It still does not become proof that a particular company was compromised. Conversely, the absence of public exploit code does not make an affected gateway safe. Private exploit development, incomplete disclosure, and later publication are all possible. Defenders can patch promptly without pretending to know more than the evidence shows.

Use careful verbs in tickets and executive updates. “Affected” means the product and version fall inside the vendor’s scope. “Exposed” means an attacker could reach the relevant service path. “Attempted” means evidence shows suspicious traffic or a matching request. “Exploited” means evidence supports successful use of the flaw. “Compromised” means the attacker achieved an unauthorised effect or presence. One word should not stand in for all five.

This vocabulary prevents two common failures. The first is panic: declaring every vulnerable appliance breached and ordering an organisation-wide rebuild without local evidence. The second is complacency: deciding that “no known exploitation” permits waiting for a routine monthly window. Critical pre-authentication code execution on a perimeter device calls for fast remediation; the scale of investigation and recovery should follow exposure and evidence.

Preserve the records that can answer those questions before update work rotates or replaces them. Useful sources may include gateway and VPN logs, edge or upstream firewall records, central network telemetry, management audit events, update history, and remote-access authentication records. What is available varies by Check Point deployment and logging configuration. Document the retention window before drawing a conclusion from a search.

A clean search is bounded evidence. “No suspicious VPN negotiation traffic was found in retained gateway and upstream firewall logs from 1 September through the 13 September repair” says what was checked and what dates remain visible. “No attack happened” claims knowledge the logs may not provide. The first sentence can guide a risk decision; the second invites false confidence.

Indicators of compromise are useful when a vendor or responder has a known pattern to publish. Check Point had not published indicators for these two flaws in the public material reviewed for this article as of 13 September. Their absence is not a clean bill of health. It means the team should rely on its architecture, baseline behaviour, retained traffic, and any later vendor updates rather than matching one promised string.

Leave the case open long enough to revisit new evidence. Record which advisories were checked, at what time, and who owns the follow-up. If Check Point, NCSC-NL, or another authoritative source later confirms exploitation or publishes detection detail, the team can rerun focused checks against preserved data instead of discovering that the relevant week has already expired.

The temporary network rule has a narrow job

Check Point gives Site-to-Site VPN operators a mitigation for systems that cannot be fixed immediately. Disable the implied VPN rules and define access to UDP ports 500 and 4500 only for the specific peer IP addresses. This turns a broad listener into a service available only to known tunnel partners, assuming those partners use stable addresses and the policy is applied correctly.

The rule follows the mechanism. An external attacker needs to reach the VPN negotiation service to present the malicious certificate data. Restricting the source addresses removes that path for strangers while preserving it for named peers. It can buy time for an appliance awaiting a supported update or a controlled change window.

It is still a temporary control. A trusted peer network could be compromised. A mistaken address object could remain broad. Another interface or policy path could expose the same ports. A locally managed Spark appliance cannot use this published mitigation, according to Check Point. Remote-access users also do not arrive from a short list of fixed corporate peer addresses.

Test the effective rule from both sides. Confirm that an approved site-to-site peer can still establish its tunnel, then test from an external address that should have no access. Review the installed policy on the gateway rather than only the policy object on the management server. A change that exists in the console but never reached one cluster member does not narrow that member.

Operational safety matters because the gateway carries production traffic. Record current policy, peer addresses, rollback steps, and an owner before changing implied rules. Coordinate with network and service owners so a failed partner tunnel is noticed quickly. Urgency is a reason to make the change observable, not a reason to skip the checks that keep it reversible.

Do not create a homemade certificate filter unless Check Point explicitly supports it. A network device may process IKE, NAT traversal, remote-access VPN, and management traffic across several components. A speculative signature based on incomplete public detail can block legitimate negotiation while missing the vulnerable parser path. The vendor update changes the affected code; source restriction reduces who can reach it.

Public reachability should also be tested from outside the organisation. An internal diagram may show the gateway behind another firewall, while a cloud route, secondary address, disaster-recovery interface, or partner path still reaches it. Query the actual routing and policy state. External observation can confirm what a stranger sees, but keep testing defensive and authorised.

Once the patch is verified, decide whether the narrow peer rule should remain. Explicit allow-lists for stable site-to-site partners may be a sensible permanent reduction in attack surface. That choice needs normal network design review because partner addresses change and emergency exceptions tend to outlive their owners. A durable rule has monitoring, change ownership, and a tested failure path.

The practical model is simple. The update removes the known software defect. The temporary rule lowers opportunity while the defect remains. Verification proves which systems received the update. Evidence review asks whether the earlier opportunity appears to have been used. Each control answers a different question.

A response sequence for real fleets

A perimeter patch can become chaotic when the asset list, network team, security team, and service provider each hold part of the truth. One incident owner should join those pieces into a finite sequence and keep a record that the next shift can read.

  1. Open one response record and name an owner. Record the two CVEs, the 9 September vendor publication, the 10 September NCSC-NL warning, and the time your organisation began work. Separate confirmed facts from forecasts and local unknowns.

  2. Find every relevant Check Point system. Include Security Gateways, Security Management Servers, centrally managed Spark appliances, locally managed Spark appliances, cluster members, standby systems, branch devices, and disaster-recovery equipment. Search management inventories, support portals, network diagrams, certificate records, monitoring, cloud accounts, and provider records rather than trusting one source.

  3. Record effective version and role. Capture the running branch, Jumbo take or Spark build, management model, VPN mode, cluster role, and support status from each device. Mark R82.20 as unaffected only where the running system actually reports R82.20. Flag end-of-support branches for an explicit vendor or service-provider decision.

  4. Map who can reach the negotiation service. Note whether UDP 500 and 4500 are public, limited to site-to-site peers, available through another perimeter, or unreachable from untrusted networks. Check real policy and routes. Treat remote-access gateways as internet-facing unless an effective upstream control proves otherwise.

  5. Preserve the first useful evidence. Export relevant gateway, VPN, management, upstream firewall, and central network records before updates or restarts affect retention. Record dates, time zones, collection commands, and known gaps. Do not delay an exposed system for a perfect forensic image when a short, safe collection can preserve the highest-value records.

  6. Apply temporary restriction where it fits. For Site-to-Site VPN, follow Check Point’s exact mitigation and allow UDP 500 and 4500 only from specific peer addresses while the fix is pending. Test approved peers and rejected sources. Do not apply this instruction blindly to Remote Access VPN or locally managed Spark systems.

  7. Install a supported fix. Use LivePatch Take 24, the fixed Jumbo floor, the fixed Spark build, or a later supported release identified by Check Point for that branch. Follow cluster and change procedures. If the system is on an end-of-support release, escalate for a supported migration or vendor-approved response instead of inventing a package path.

  8. Verify every running node. Save cpinfo -y CPupdates and cplp list results where LivePatch applies. Record Jumbo takes or Spark builds where those paths apply. Check each cluster member, management server, branch gateway, and standby node. Confirm service health, tunnel establishment, policy installation, and management communication after the change.

  9. Review the bounded exposure window. Search the preserved evidence for unusual negotiation traffic, crashes, restarts, policy changes, management activity, or unexpected internal connections. State exactly which sources and dates were reviewed. Widen the investigation only when reachability, authority, or evidence supports it.

  10. Write a coverage statement. List systems fixed, systems unaffected, systems isolated, systems awaiting vendor action, records reviewed, and remaining unknowns. Attach per-node receipts. Assign a deadline and owner to every exception, especially an old branch or offline standby system that could return later.

The order can overlap safely. A security analyst can preserve central logs while network engineers restrict peer access and appliance owners stage the fix. What should not happen is silent fragmentation, where one team assumes another verified the standby member or called the provider about the old Spark box.

Keep communication proportional. Service owners need to know whether a tunnel interruption is possible and whom to call. Leadership needs the size of the affected fleet, the repair deadline, and any unresolved high-risk exception. They do not need an unverified claim that attackers are already inside. A precise update builds more confidence than a red banner with no denominator.

The work is complete when the organisation can answer three questions with evidence. Which systems could process the vulnerable certificate path? Which of those systems now run a verified fix or have an effective temporary restriction? What local evidence was available for the earlier window, and what did it show? If one answer is a guess, keep the record open.

What this incident says about boundary appliances

A VPN gateway is often described as a security control, which can make teams treat it differently from an ordinary server. It blocks untrusted traffic, enforces policy, and creates encrypted connections. It also runs complex parsers, accepts internet input, receives updates, holds configuration, and sometimes trusts a central management plane. It is software at the boundary, not a magic boundary around software.

That should shape routine operations before the next advisory. Maintain a live inventory of gateways and management systems with owners and support dates. Send appliance logs to a protected central destination with enough retention to cover delayed disclosure. Rehearse emergency patching and failover. Know which site-to-site peers can be explicitly allowed and which remote-access services must remain broadly reachable.

Verify automated repairs as a normal practice. Automation solves scale, but its own output can hide exceptions. A monthly sample may be enough for ordinary maintenance; a critical pre-authentication flaw deserves complete per-node proof. Build the command output and version collection into the deployment job so the receipt appears automatically rather than being assembled in a late-night spreadsheet.

Reduce the authority behind the gateway where architecture permits it. Separate management access from user VPN traffic. Limit which systems a gateway can initiate connections toward. Protect management servers as high-value control-plane systems. Use distinct administrative identities, multi-factor authentication, and central audit records. These controls cannot fix a certificate parser, but they can make code execution on one component less useful and easier to see.

Retire end-of-support appliances before an emergency exposes the cost of delay. Old network equipment often survives because it is stable, remote, or owned through a service contract nobody wants to reopen. A critical advisory turns that convenience into a constrained response: the current fix path may not exist, replacement may require an outage, and the team may not have recent configuration backups. Support status belongs in risk reviews while there is still time to plan.

Ask providers for evidence, not reassurance. If a managed service operates the Check Point fleet, request the affected asset count, running versions, chosen fix, per-node verification, exception list, and exposure review. “The vendor has released a patch” describes availability. “All 24 gateways and four management nodes report the fixed bundle, with two offline spares blocked from service until update” describes coverage.

This is the same discipline that makes coding agents safe enough to use in production: authority belongs inside tested boundaries, and controls need receipts. The Secure Harness develops that model for software-producing agents. A perimeter appliance is a different system, but the operational lesson travels well. A policy you cannot verify is an intention.

The September Check Point flaws deserve fast action because they sit in unauthenticated certificate processing on systems that may face the internet. The public record as of 13 September does not justify telling every customer they were breached. It justifies a short repair clock, careful language, and a local evidence trail.

Patch the code. Check every node. Keep the earlier window attached to what the logs can actually prove. That is calmer than panic and stronger than reassurance.

If you want more security news translated into decisions you can use, the newsletter is one email per month. The signup is on this site.

Sources