Check Point Said "No Evidence" of Exploitation. Thirteen Days Later, CISA Had Confirmed Two Attacks — One Running Since July.

On September 9, 2026, Check Point patched two critical, unauthenticated remote-code-execution bugs in its VPN certificate handling and said plainly it had seen no evidence anyone was exploiting them. By September 22, CISA's Known Exploited Vulnerabilities catalog said otherwise — twice. One of the two newly KEV-listed bugs had reportedly been under quiet, targeted attack since July 23, more than six weeks before the public ever heard its name.

The timeline

What Check Point actually said, and when

That is a narrower claim than it first sounds, and worth being precise about: Check Point's September 9 statement describes what it knew at the time of patching, not a permanent assessment. The attacks it now confirms began three days after the fix shipped — a classic n-day race against unpatched, internet-facing gateways, not a vendor sitting on evidence of an active breach. The accountability question isn't whether Check Point lied on September 9. It's why a bug worth 9.8 and reachable without authentication sat unexploited in the public record for only three days before attackers moved — and why the advisory that finally confirmed it, 13 days later, arrived bundled with a second, much older problem.

The forecast that held up

The bug that ran for two months before anyone said its name

CVE-2026-93616 is the less-discussed half of the Sept 22 advisory, and it's the one with the real accountability gap. It's a path-traversal and arbitrary file-upload flaw in Check Point's Security Management Server, Multi-Domain Security Management, Log Server and SmartEvent — the consoles that manage the gateways, not the gateways themselves. Check Point's own advisory labels it "Zero-day, limited exploitation, fix available today" and dates the earliest observed activity to July 23, 2026. There was no public advisory, no CVE, and — as far as the published record shows — no customer notification describing an active attack between that date and September 22.

Confirmed vs. inferred

• Confirmed by Check Point directly: exploitation of CVE-2026-85102 against Spark customers starting Sept 12; a small number of targeted exploitation events for CVE-2026-93616 dating to July 23; indicator certificates including the subject CN=vpn,OU=users,O=global (Check Point says the list is "not exhaustive").
• Confirmed by CISA directly: both CVE-2026-85102 and CVE-2026-93616 show active exploitation sufficient for KEV listing, with a federal remediation deadline of Sept 25, 2026.
• Inferred, not confirmed: that NCSC's Sept 12 warning and the first attacks are causally linked rather than coincidental; the full scope or duration of the CVE-2026-93616 intrusions; whether any victim data left the management plane.
• Not released by Check Point: victim counts or names for either CVE, a technical root-cause writeup beyond the advisory text, or an explanation of why CVE-2026-93616's July activity wasn't disclosed before it was bundled with the September gateway advisory.

What to actually do

1. Patch Security Gateway and Spark Firewall (centrally or locally managed) running R81, R81.10, R81.10.X, R81.20, R82, R82.00.X or R82.10 against CVE-2026-85102 via sk1000117 — do not treat the Sept 9 release date as evidence of safety; exploitation began three days after it shipped.
2. Patch Security Management Server, Multi-Domain Security Management, Log Server and SmartEvent against CVE-2026-93616 via sk1000171. Note Check Point's own caveat: LivePatch Take 28/29 does NOT address this issue — a hotfix path that looks current but isn't.
3. Hunt for the published indicator — VPN client certificates with subject CN=vpn,OU=users,O=global — while treating Check Point's own "not exhaustive" caveat as the ceiling of what this one IOC will catch.
4. Where you can't patch immediately, restrict VPN access (UDP 500/4500) to known peer IPs and disable implied VPN rules, per Check Point's and CSA Singapore's shared mitigation guidance.
5. Watch for internal port and service scanning as a secondary indicator — Check Point flags this as the follow-on behavior after initial access via CVE-2026-85102.

CN=vpn,OU=users,O=global

Why it matters, and the accountability ask

None of this requires Check Point to have acted in bad faith to be a problem. A critical, unauthenticated, internet-reachable VPN bug going from patch to confirmed exploitation in three days is now a normal speed for this class of appliance — CVE-2026-85102 isn't unusual on that axis. What's unusual, and what deserves a direct answer, is CVE-2026-93616: a management-server compromise path that, on the vendor's own timeline, was running for roughly two months before a single customer outside the handful targeted could have known to look for it. If Check Point knew about targeted exploitation in late July, customers deserved to hear about it before it was folded into an unrelated September advisory about a different component. If Check Point didn't confirm the activity until closer to September, that's a different and more forgivable story — but it's one the advisory doesn't tell, and it's the one worth asking a Check Point account team to answer directly before trusting the next "no evidence of exploitation" at face value.

CVE data current as of 2026-10-05live record →