Vulnerability ManagementThreat IntelligenceIncident Response
When a firewall gets breached, the first thing an incident responder does is open the firewall logs. Who connected, from where, at what time, and what the policy allowed. In a Check Point estate, those logs live on the Log Server or the Security Management Server, and correlated events live in SmartEvent.
On 22 September, Check Point disclosed that attackers had been exploiting a flaw in exactly those servers since 23 July, two months before a fix existed.
The flaw is CVE-2026-93616, rated 9.8 on CVSS. According to Check Point's advisory, it combines path traversal with unsafe file upload in the management web service. An attacker who can reach that service over the network can write a file outside the intended directory and then execute a script or load an arbitrary Java class. No login is needed.
The affected products are the ones that sit at the centre of a Check Point deployment:
Check Point says it saw "a handful of pinpointed attacks", with the first on 23 July 2026. Fixes were published on 22 September, so the flaw was a live zero-day for about two months. Check Point has not named an attacker or described what the intruders did after getting in. CISA added the CVE to its Known Exploited Vulnerabilities catalog on the same day and gave US federal agencies until 25 September to fix it.
Some early reports gave 12 September as the start of exploitation. That date belongs to a second, separate Check Point flaw disclosed in the same advisory (see below). For CVE-2026-93616, Check Point's own date is 23 July.
Per SecurityWeek and The Hacker News:
| Version | Fix |
|---|---|
| R82.20 | R82.20 Security Hotfix |
| R82.10 | Jumbo Hotfix Accumulator Take 45 |
| R82 | Jumbo Hotfix Accumulator Take 127 |
| R81.20 | Jumbo Hotfix Accumulator Take 170 |
| R81.10 | Jumbo Hotfix Accumulator Take 192 |
Two details are easy to miss. First, standard LivePatch updates do not fix this flaw. You need the hotfix or Jumbo take listed above. Second, R81, R80.x and older are end-of-support. If a management or log server is still on one of those, upgrading it is now urgent.
The advisory also covers CVE-2026-85102, a certificate validation flaw on Security Gateways and Spark firewalls running R81 to R82.10. It was patched on 9 September, and exploitation started three days later, on 12 September. Check Point says the attempts used VPN certificates with subjects such as CN=vpn, CN=vpn-user and CN=vpnuser. It advises watching for "second stage activity originating from suspicious logged-in users via Mobile Access", usually followed by internal port scanning. Unlike the management flaw, this one was patched first and exploited afterwards. That gap is short, but it is still time for defenders to act.
Most coverage treats this as "firewall vendor has a critical bug". The more important detail is in the product list.
A compromised gateway lets an attacker through. A compromised management server lets an attacker change what the gateways enforce. A compromised log server or SmartEvent lets an attacker change what the security team can see afterwards. Code running on the box that stores the logs can delete lines, change them, or stop new ones from being written. Any investigation then relies on records the attacker could have edited.
That is why one line in the hunting guidance matters more than it looks. Alongside the indicators in Check Point's support article sk1000171, responders are advised to preserve logs outside the management server itself. If the only copy of your firewall logs has been sitting on a server that was exploitable for two months, you can't be sure those logs are complete.
1. Patch, then restrict. Apply the hotfix or Jumbo take for your version. Then make sure the management web service (TCP/19009) can only be reached from administrator IP addresses. Check Point recommends putting the server behind a gateway and using Trusted Clients rules in SmartConsole. Nothing on the public internet should be able to reach it.
2. Hunt as if you were exposed since July. Run the sk1000171 indicator checks on every Management, MDS, Log Server, MDS Log Server and SmartEvent node, not just the primary. Then look for:
../ and encoded variants) in management-service requests;3. Check the logs against an independent copy. Wherever possible, compare what the management server says happened with a copy it couldn't have altered: a SIEM, a syslog collector, or network flow records from another device. Gaps, sudden drops in volume, or events that exist in one place but not the other are findings in their own right.
4. For gateways, check Mobile Access. For CVE-2026-85102, review Mobile Access logins since 12 September for the certificate subjects above, and look for internal scanning that follows a VPN session.
This is a job for Obiguard SOC, and the boundary comes first. SOC does not scan Check Point appliances or tell you which Jumbo take you're running. Its CVE Radar scans dependencies in your code repositories, not firewall firmware. Patching and running Check Point's own indicator checks are still your first steps.
What SOC gives you is the thing step 3 assumes you already have: a copy of your security logs that doesn't live on the security appliance.
A second copy, off the box. Check Point can export logs over syslog, and SOC ingests logs through the OpenTelemetry Collector, which can receive syslog. Forward gateway and management logs as they're written, and every event also lands somewhere an attacker on the log server can't reach. If a line later goes missing from SmartEvent, it is still in SOC.
Silence is a signal. SOC raises alerts from changes in log volume, not only from rule matches. A log source that suddenly drops off, or a management server that goes quiet at 3 a.m., creates an alert instead of passing unnoticed. Code running on a compromised log server often changes the log stream, and a drop in volume is one of the few signs you can see from outside the box.
One timeline for the hunt. In Live Logs, a full-text search for 19009 or for CN=vpn-user shows the matching events from every forwarded source together, with host and level filters for narrowing. Each alert keeps an evidence timeline linked back to the raw events that triggered it. When you are reconstructing two months of possible access, you work from the original records.
We made a similar point last week about malware that takes its orders from AI models: correlation only works if the evidence ends up in one place. This week adds a second requirement. The place where the evidence ends up should not be a system the attacker can edit.
Check Point's customers did nothing wrong here. The flaw was unknown, the attacks were few and targeted, and the fix came with indicators. The difficult part is what comes after the patch: working out what happened during the two months the flaw was open.
So the question is not have we applied the hotfix? By the end of this week, most teams will have. It is: if the attacker was on your log server in August, is there a copy of those logs they couldn't have touched?
Explore Obiguard SOC or talk to us about streaming your firewall, endpoint and application logs into one independent timeline, so the evidence survives even if the box that produced it doesn't.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →