Check Point Spark Under Attack: NC Branch Firewall Alert

The 60-second version: Two Check Point flaws, both rated 9.8 on the 10-point CVSS scale, which puts them in the critical band just short of the maximum, are being exploited right now. The one that matters most to a small plant is CVE-2026-85102, hitting Spark, Check Point's firewall line for small and medium businesses and the providers who manage them. Its fix has existed since September 9. Check Point says it began seeing a wave of attempts on September 12, which is when it started observing them rather than necessarily when they started. CISA listed both on September 22, due September 25.

First question, before you read another word: do you have a Check Point box at all? You may well not know, and that is not a failing. There are two ways to find out and you want both, because either alone gives a wrong answer.

Walk to the network closet and read the labels on everything in the rack, not only the box the incoming cable lands on first. The incoming cable may land on an ISP modem or router first, putting a Check Point second or third. Photograph them with your phone.

Then ask whoever manages your network for the device list, because a gateway can be virtual, or run from a provider's console, and never appear as a labelled box at all. If the rack and the provider both come back with no Check Point, skip to the last section, the only part that applies to everybody.

The box nobody was ever billed for

Start here, because this is the part that catches people, and it has nothing to do with the main building.

A small firewall at a second site in the Triad may well be a unit installed by whoever sold the internet circuit, as a one-time setup with no ongoing agreement. That is the case to check for: such a box misses the patch report because it never made the inventory, and misses the inventory because nobody was ever billed for it.

Nobody neglected it. A box like that might email an alert or ship a log somewhere, but if no one set that up, the signal goes to nobody. A device that never asks for attention does not get any. The cost lands later: with no credentials in the building, you face a call to a reseller who may no longer have the account, or a factory reset and a rebuild of a configuration nobody wrote down. Price it before you need it: it depends on who still has access and what was written down. None of it comes from the vulnerability. You are paying for however long nobody was on the hook.

Preferred Data Corporation has served North Carolina manufacturers since 1987, and runs network infrastructure for them today. If you want a second opinion on what is in that closet, call (336) 886-3282.

What is being exploited, and does it reach you?

CVE-2026-85102 is a certificate validation flaw in VPN negotiation that lets someone with no account and no password run code on the firewall. Check Point's September 22 advisory states that "starting September 12, 2026, we observed a wave of exploitation attempts against Spark customers" globally, and that Check Point "disclosed the vulnerability and released fixes on September 9, 2026."

Read the affected list carefully, because this is where people talk themselves out of patching. The advisory names R81, R81.10, R81.10.X, R81.20, R82, R82.00.X and R82.10, current supported builds among them, not only end-of-support ones. A recent release is not an exemption.

CISA's wording in the Known Exploited Vulnerabilities catalog is the clearest single line available: Check Point Security Gateway and Check Point Spark Firewall "using Site to Site VPN or Remote Access VPN contain an improper certificate validation vulnerability which could allow an unauthenticated remote attacker to execute arbitrary code on the Gateway." Both entries went in on September 22 with a due date of September 25, and ransomware campaign use recorded as Unknown.

The second flaw, CVE-2026-93616, is a pre-authentication path traversal in Check Point's management web service, also 9.8. Do not skip it just because you run no management server yourself: Check Point sells Spark to managed providers with "central posture visibility of all customers with multi-tenant account view," so if somebody manages your firewall, their management server sits in your blast radius. Ask them about it by name.

Both are being exploited, which is what puts both in KEV. The difference is shape, not seriousness: one is broad and current, the other narrow, quiet and unfixable until the advisory shipped, leaving management servers exposed to a known-exploited flaw for two months.

Key takeaway: Being on a supported release is not the same as being unaffected. R82.10 is on the list.

Centrally Managed or Locally Managed? Both are affected, and the word tells you where to check

Check Point lists Spark twice in the affected-products table, once as Centrally Managed and once as Locally Managed. Both are vulnerable, so the word does not change your exposure.

A Centrally Managed Spark answers to a console; a Locally Managed one is configured on the device itself. Neither settles what you care about: a locally managed unit can be set up with automatic updates and alerting, and a unit visible in a console can sit unread for a year. The mode tells you where to look, not whether anyone is looking.

Do not try to settle this from a login screen: a centrally managed unit can still offer local administrative access while its policy lives on a management server, so reaching a config page proves nothing. Ask whoever administers the device to read you the status it reports.

So ask the monitoring question separately rather than inferring it. Five questions, in writing, with a reply-by date of Friday:

1. Do we have any Check Point gateway or Spark appliance anywhere, including warehouses, annexes, leased sites and building-to-building links?
2. For each one, is it Centrally Managed or Locally Managed, and who holds the credentials?
3. What build is each on, and on what date was it applied?
4. Who checks that each device is up to date, and what update, logging or alerting is actually configured on it?
5. Which VPN modes are enabled on each one, Site-to-Site as well as Remote Access and Mobile Access, and does each still need to be? CISA names Site to Site and Remote Access VPN both, so a "no" covering only remote access answers half the question.

You do not need to understand the answers technically to grade them:

• A good answer has a build number and a date applied, names a person for the credentials, names who checks the device and what alerting exists, and answers each VPN mode separately, Site-to-Site included.
• A bad answer is "we handle that," "we are fully patched," or "everything is up to date" with no version string anywhere in it.
• No answer by Friday is itself the finding, and a bigger one than this CVE.

If the replies come back in the "we handle that" column, that is worth a second opinion before Friday rather than after. Preferred Data Corporation is in High Point, on-site within 200 miles across the Triad, Greensboro, Winston-Salem, Charlotte and Raleigh. Call (336) 886-3282.

That last question earns its place: remote access switched on years ago and never switched off is a standing exposure regardless of this CVE.

How would we know if somebody already got in?

This paragraph is for whoever manages the box rather than for you.

Hand this to your provider: the advisory names three certificate subjects seen in the attacks, CN=vpn,OU=users,O=global, CN=vpn-user,OU=users,O=global and CN=vpnuser,OU=users,O=global. It tells administrators to review logs for anomalous certificate-based Mobile Access logins and to "look for second stage activity originating from suspicious logged-in users via Mobile Access," noting it "often involves internal port and service scan." For the management flaw, Security Affairs reported on September 22 that the fix arrived in an R82.20 Security Hotfix, with a temporary mitigation of putting the management server behind a firewall and permitting only trusted IP addresses.

What is not known matters too. Check Point knows of a handful of customers already attacked, and an undetected compromise reports nothing. For CVE-2026-93616, The Hacker News reported on September 22 that the advisory names no target, no actor, and nothing about what followed access. Anyone telling you who is behind this, or that the intent was ransomware, is ahead of the evidence.

Key takeaway: "We applied the update" and "we checked whether anything happened first" are two different answers, and on a box reachable since September 12 you want both.

Does a federal deadline mean anything to a private plant?

Not as an obligation. CISA's September 22 alert binds federal civilian agencies only, and the September 25 date comes from a risk-based schedule in Binding Operational Directive 26-04 whose criteria table CISA publishes as an image, so read it there rather than taking our summary of it.

Borrow one thing from it: CISA flags both entries for forensic triage, meaning agencies must check whether anything already happened, not only patch. And find the patch window in your provider agreement. If it says thirty days for internet-facing gear, ask whether thirty is right, given that the gap between this fix and the observed wave was three days. SecurityWeek has the vendor-neutral framing if you want a second read.

The plan, and the part that applies even without Check Point

1. Today: send the five questions in writing, with a Friday reply-by date.
2. Today: if any answer names a Check Point gateway or Spark, escalate it.
3. Today, before the hunt starts: cut the exposure on every affected surface, while the evidence is still intact. Have whoever manages them restrict who can reach each affected gateway from the internet, and separately restrict who can reach any Check Point management, log or SmartEvent server, permitting only trusted addresses. Containing one is not containing the other: the temporary mitigation Check Point published covers the management server, and it does nothing about an exposed VPN. Both flaws are being exploited, so both get contained, whichever one a vendor mitigation happens to address. Do not reboot, reset or rebuild to do any of it: those destroy the evidence the hunt depends on. A box left reachable for the days a hunt takes is a box that can be compromised during the hunt, which is the failure this ordering exists to prevent.
4. This week: have whoever manages them look for signs of compromise on the gateway and on any Check Point management, log or SmartEvent server, across the whole window each sat unpatched and as far back as logs are retained. Both flaws are exploited, so each side you actually have gets hunted. A hotfix rewrites files, processes and logs even without a reboot, and that is the evidence this hunt needs. Three cautions on scope. Do not use September 12 as the starting line: that is when Check Point began seeing a wave, not when exploitation began, and it has not said whether anything landed before. And do not let it stop at Mobile Access logins: those carry Check Point's published certificate indicators, but CISA lists Site-to-Site VPN as vulnerable too, and a Site-to-Site-only gateway may have nothing in that log. Ask what evidence exists for each enabled mode, and treat "the Mobile Access logs were clean" as an answer about one mode, not the device. Third, the management side has no published indicator list: Check Point named certificate subjects and a login pattern for the VPN flaw, nothing comparable for CVE-2026-93616. Agree first what a hunt there examines, and treat a "nothing found" with no artifact anybody can name as an unanswered question, not a clean result.
5. If the hunt finds anything on either side, stop here and change track. Do not patch, reboot, reset or rebuild that machine: all of it destroys evidence somebody will need. Isolate it, leave it powered, and call your insurer's hotline and a responder. Treat every credential and key on or behind it as exposed. The question is now what was reached inside the network: patching closes the door, it does not remove whoever is already through.
6. Once every hunt that applies to you comes back clean against artifacts somebody can name, or your responder says go: apply the fix on every affected unit, checking the full version list including R82.10. If you have a separate management, log or SmartEvent server, it needs its own fix as well: CVE-2026-93616 takes the R82.20 Security Hotfix, and "the firewalls are patched" does not cover it. On a locally managed all-in-one there is no second server, so the gateway hunt is the whole gate and nothing is waiting on a hotfix you do not need.
7. This week: turn off every VPN mode enabled and not genuinely needed, Site-to-Site included. Old tunnels to a site you gave up or a vendor you dropped are the easy wins. For links you still use, the fix is the update.
8. This month: put every internet-facing device, other buildings included, on one list with an owner and a patch window.

Steps one to seven close this month's hole, assuming step five stayed hypothetical. Step eight still helps when the next advisory lands, from any vendor, because the work of finding out whether it applies is already done.

Somebody has to own the box at your second building. If nobody can name who, that is the finding, and it is fixable once. Preferred Data Corporation, 1208 Eastchester Drive, Suite 131, High Point, NC 27265. Call (336) 886-3282, or see our network infrastructure services.

Short answers

We do not use Check Point. Can we stop reading?

For this advisory, yes, but keep the last step. An internet-facing appliance with no named owner is not a Check Point problem, and we have written the same post about SonicWall and Fortinet gear.

Our Spark sits behind the ISP router. Are we insulated?

Probably not in the way you mean. The flaw is reached through VPN negotiation, and a VPN endpoint has to be reachable to work. If Site-to-Site or Remote Access VPN terminates on that box, traffic gets to it.

Is this ransomware?

Unknown, and nobody has said so. CISA records ransomware campaign use as Unknown for both, and Check Point has not described what followed access on the management flaw. Treat it as unauthenticated code execution on your perimeter, serious enough without a label.

We patched on September 10. Are we fine?

Probably, for CVE-2026-85102, if what you applied was the September 9 fix and not an unrelated hotfix. Confirm the build against the full affected list including R82.10. Check Point has not said whether any attempt before September 12 succeeded, so patching early is not the same as nothing having happened. The management flaw is separate and its fix shipped September 22.

Who should own the answer internally?

Whoever can produce a list of every internet-facing device by Friday. If nobody can, that is the larger finding.

Related Resources

• Check Point SmartConsole CVE-2026-16232, July's separate management-plane event
• Check Point IKEv1 CVE-2026-50751, the earlier round of VPN exploitation
• A business firewall buying guide for North Carolina if the answer is "replace it"
• Cybersecurity services and managed IT from Preferred Data Corporation, High Point, NC