Check Point's Two-Front Fire Drill: What MSSPs Must Hunt After Patching CVE-2026-85102 and CVE-2026-93616

Two Advisories, One Bad Week for Check Point Admins

Check Point spent this week issuing not one but two "action required" advisories. The first covers CVE-2026-85102, an unauthenticated remote code execution flaw in VPN-enabled Security Gateways, now under active exploitation. The second covers CVE-2026-93616, a pre-authentication path traversal in the Management Server that leads to script execution, also being exploited in targeted attacks [1][3]. Both have been added to CISA's Known Exploited Vulnerabilities catalog, and the KEV listing carries a federal remediation deadline of September 25 [5][18].

These are not the same bug wearing two names. They sit on different components, they were disclosed on different timelines, and Check Point patched them separately [1][16]. CVE-2026-93616 is a classic CWE-22 path traversal, unauthenticated, landing on the management plane where it can execute scripts before anyone logs in [12][14]. Check Point has confirmed it was exploited in targeted attacks against a limited set of customers before a fix existed [10][11]. CVE-2026-85102 is the louder problem for anyone running a distributed VPN estate: it allows remote access without authentication on the gateway itself [19][20].

Put those two together and you get a genuinely unpleasant scenario for an MSSP managing Check Point at scale: the device customers trust to keep intruders out is, in this case, the thing that let them in.

Who's Affected

If you have Check Point Security Gateways with VPN enabled, or a Check Point Management Server reachable from anything other than a tightly locked management network, you're in scope. That covers a lot of mid-market and enterprise perimeters, plus every MSP and MSSP managing Check Point on behalf of clients. The exploitation activity reported so far isn't opportunistic noise from a single script kiddie crew, it's targeted enough that Check Point felt the need to publish indicators rather than just a CVE number and a shrug [1][2].

Why "Patch Installed" Is Not the Same as "Incident Closed"

Here's the part that gets lost in the rush to close the ticket: CVE-2026-85102 is an authentication bypass on the perimeter device. Once bypassed, an attacker is inside the trust boundary the VPN exists to protect. Applying the hotfix stops the next attacker from walking through the same door. It does nothing about the attacker who already walked through it last Tuesday and is currently sitting on a session, a scheduled task, or a set of harvested credentials.

This is the distinction that separates a vulnerability management exercise from an incident response exercise, and it's exactly where a lot of patch-and-move-on workflows fail their customers. Confirming the hotfix version number tells you the gateway is no longer vulnerable going forward. It tells you nothing about what happened between the exploitation window opening and the patch landing on that specific box.

What the Published Indicators Actually Look Like

Check Point and independent researchers have published the behavioral signatures worth hunting for, and they're specific enough to act on [1][2]:

• Rogue VPN sessions that don't map to a known user, device, or expected geography, particularly ones established during the exploitation window before the patch was applied.
• LDAP/LDAPS scanning originating from the VPN interface itself, which is a strong signal that an attacker landed on the gateway and is now enumerating the directory it talks to, looking for a path to domain credentials.
• Certificates presented from source IPs tied to anonymization services, a pattern consistent with an attacker masking origin while abusing the authentication bypass.

None of these show up in a patch compliance report. They show up in gateway logs, VPN session logs, and directory-side authentication logs, assuming those logs are actually being collected somewhere a human or a detection engine can query them.

What an MSSP Should Do Right Now

1. Patch the gateway and the management server on their own tracks. These are separate hotfixes on separate timelines. Treat them as two change tickets, not one [1][16].
2. Pull VPN session logs and directory auth logs back to the earliest date the CVEs could have been exploited, not just from the patch date forward. If you don't have retention that far back, that's the actual gap, not the patch.
3. Hunt for the three published indicators above across every managed gateway, not just the ones that threw an alert. Quiet gateways are not necessarily clean gateways.
4. Check management server access logs for path traversal patterns consistent with CVE-2026-93616, pre-auth requests probing directory structure outside the expected web root.
5. If you find a match, isolate first, investigate second. A compromised gateway or management server sitting on the network while you write up findings is a compromised gateway or management server that's still reachable.
6. Rotate credentials and certificates touched by the management plane. An attacker with script execution on the management server had a window to read configuration, not just poke at it.
7. Document the federal KEV deadline for any client under regulatory obligation to track it, September 25, and treat it as a floor, not a target [5][18].

The Log Pipeline Is the Scene of the Crime

This is the part that separates a mature Global SOC from a help desk with a security label on it. The indicators Check Point published aren't detections you'll spot by eyeballing a dashboard once a week. Rogue VPN sessions and LDAP scanning from a VPN interface look, at a glance, like normal network chatter unless you know exactly what to correlate against what. That correlation requires the VPN logs, the directory logs, and the certificate metadata to be flowing into one place, continuously, with someone or something watching it in real time.

At Vijilan, this is where ThreatRespond™, our Managed XDR service, earns its keep. It's built to ingest exactly this kind of perimeter and identity telemetry, whether it's coming off Check Point gateways, Microsoft Entra, Okta, or a CrowdStrike Falcon-monitored endpoint sitting behind the VPN, and correlate it against published indicators the moment they're released, not the next time someone happens to run a report. For partners who've already invested in a SIEM or log pipeline of their own, ThreatHunt™ lets our analysts run this exact kind of indicator-driven sweep across your existing tooling.

Isolate, Don't Just Reboot

When a hunt turns up a match, the clock that matters is the one between confirmation and containment. ThreatContain™ gives our Global SOC the ability to isolate a compromised gateway or management server directly, cutting off the session or the host rather than waiting for a change window. That's a materially different posture than confirming a hotfix installed and calling the ticket closed. A patched, still-compromised gateway is not a resolved incident, it's a resolved vulnerability with an open incident sitting underneath it.

What This Means for Your Client Conversations

If you're an MSP or MSSP fielding calls about this right now, the honest answer to "are we affected" isn't the patch version, it's whether anyone has actually looked at the logs from before the patch went in. That's a harder conversation than "we're patched," and it's the right one to have. Vijilan works alongside partners on exactly this kind of indicator-driven hunt, and we never compete with our partners for their clients. If you want a second set of eyes running the Check Point indicators against your client environments this week, that's a conversation worth having before September 25 turns into a deadline you're explaining after the fact.

Questions about scope or coverage for this specific advisory? Reach out through /msp. Pricing questions go to /pricing.

Frequently asked questions

Are CVE-2026-85102 and CVE-2026-93616 the same vulnerability?

No. CVE-2026-85102 is an unauthenticated RCE affecting VPN-enabled Check Point Security Gateways. CVE-2026-93616 is a separate pre-authentication path traversal on the Check Point Management Server that leads to script execution. Check Point disclosed and patched them separately.

Does patching CVE-2026-85102 remove an attacker who already exploited it?

No. The patch closes the authentication bypass going forward. It does not remove sessions, credentials, or footholds an attacker may have established before the patch was applied. That requires a log review and hunt covering the exploitation window, not just a version check.

What indicators should we hunt for after patching?

Check Point and independent researchers have published three behavioral signatures worth prioritizing: rogue VPN sessions with no legitimate user or device match, LDAP/LDAPS scanning originating from the VPN interface, and certificates presented from source IPs tied to anonymization services.

Is there a federal deadline tied to these CVEs?

Both CVEs have been added to CISA's Known Exploited Vulnerabilities catalog, which carries a remediation deadline of September 25 for federal civilian agencies. Organizations outside that mandate should still treat it as a hard floor for remediation timing.

How does Vijilan help partners respond to this specific advisory?

ThreatRespond, our Managed XDR service, ingests VPN, directory, and certificate telemetry and correlates it against published indicators like these. If a hunt confirms compromise, ThreatContain gives our Global SOC the ability to isolate the affected gateway or management server directly.