If You Run a Gateway With VPN Enabled, Stop Reading and Go Patch
I'll put the important part first, because this is one of those weeks where the news is also the action item. CVE-2026-85102 is a CVSS 9.8 improper certificate validation bug in Check Point Security Gateway and Spark Firewall, triggered during VPN negotiation, that lets an unauthenticated attacker execute code on the device. No credentials, no user interaction, just a crafted certificate thrown at any gateway with Site-to-Site or Remote Access VPN turned on. Check Point shipped the fix on September 9. Active exploitation against Spark customers started three days later, on September 12, originating from anonymization infrastructure including VPN services and proxies, which is exactly the kind of detail that tells you this is a scanning campaign, not a targeted job.
What Actually Broke
The root cause is mundane in the way most catastrophic bugs are: the certificate handling code in the VPN negotiation path doesn't validate what it's handed before acting on it. Send a malformed or forged certificate at the right point in the handshake and the gateway trusts it enough to execute attacker-controlled code, before authentication ever happens. Check Point disclosed a second flaw alongside it, CVE-2026-93616, a pre-authentication path traversal in Security Management that allows arbitrary script execution and Java class loading through the management web service. Also CVSS 9.8. Also pre-auth. That one saw limited, pinpointed exploitation as far back as July 23, months before the public advisory, which is the part of this story that should bother you more than the September mass-scanning wave.
The Three-Day Window Is the Story
Patch Tuesday discipline dies at the edge. Enterprise IT teams that patch desktops within a day still routinely leave firewall firmware sitting for weeks, because a gateway reboot means a maintenance window, a change ticket, and someone on call in case the VPN doesn't come back up cleanly. Attackers know this better than most defenders do. Three days from patch release to observed exploitation is not a long runway, and it's shrinking every cycle. Compare it to MikroTik's RouterOS SSH bypass, CVE-2026-67276, disclosed earlier this month: CERT Polska tracked active exploitation starting September 2, a full day before MikroTik even had a patch out on September 3. That one hit an estimated 122,500 internet-facing routers before the fix existed. Zero-day in the truest sense, no patch to be late on.
Not an Isolated Incident
Stack it up against the rest of September and a pattern falls out: F5 BIG-IP APM had its own unauthenticated pre-auth RCE, CVE-2026-94127, a heap overflow in the OAuth authorization path, also CVSS 9.8, also under active exploitation, also added to CISA's KEV catalog this month. Cisco's ASA and FTD firewalls got hit with CVE-2026-20349, a remote DoS that Cisco's own PSIRT confirmed was being exploited back in August before the fix landed. Four different vendors, four different perimeter products, four unauthenticated critical bugs, all inside the same 30-day window. If your network has an edge appliance doing VPN termination, access policy enforcement, or firewall duties from any of these four vendors, you had a patch to apply this month whether you noticed the advisory or not.
The Federal Deadline Tells You How Bad CISA Thinks This Is
CISA added both Check Point CVEs to the Known Exploited Vulnerabilities catalog on September 22 under Binding Operational Directive 26-04, with a remediation deadline of September 25. Three calendar days for federal agencies to patch a production firewall. That's not a bureaucratic formality, that's CISA saying an unpatched box on this list is functionally equivalent to an open door. If a three-letter agency has three days to fix this on hardware nobody there personally owns, a homelab or small business running a Spark box at the edge has considerably less excuse to let it sit.
What to Actually Do
If you're running Check Point Security Gateway or Spark on R81, R81.10.X, R81.20, R82, R82.00.X, or R82.10 with any VPN configured, get to the fixed build from SK1000117 today, not this weekend. If you manage the box remotely and can't patch immediately, disable Remote Access VPN and Site-to-Site VPN as a stopgap, check certificate-based login logs for anything that doesn't match your known peer list, and watch for post-compromise activity rather than assuming a clean scan means a clean box. The pattern this month, MikroTik, Check Point, F5, Cisco, all within the same four weeks, is a good reminder that whatever appliance sits at the edge of your network is the single highest-value target on it. It talks to the internet by design and it usually runs firmware nobody looks at until something breaks. Put it on a patch cadence that matches that risk, not the cadence you'd use for a printer.
Loading comments...