The control tower had a hole in the fence
Check Point disclosed on September 22 that CVE-2026-93616, a path traversal vulnerability in its Security Management Server, had been actively exploited since at least July 23. The bug lives in the management server's web service, which fails to properly restrict which files and folders an incoming request can touch. That failure lets an attacker with network access to the service upload arbitrary scripts and run them without ever authenticating. Check Point's fix, an emergency R82.20 hotfix, also covers Multi-Domain Security Management Server, Log Server, Multi-Domain Log Server, and SmartEvent, meaning the exposure was not limited to a single product variant.
What sets this apart from a typical firewall bug is the role the management server actually plays. It is the console that defines security policy, pushes configuration to every enforcement point downstream, and stores the logs a team would use to investigate an incident, far more consequential than a single gateway passing traffic. Compromising it potentially gives an attacker the ability to quietly change what the rest of your security stack is even enforcing, and to do so from the one place least likely to be watched by an outside detection tool, since the tool watching everything else is the thing that got hit.
Two months is the number that matters here
Check Point's advisory places the earliest known exploitation at July 23 and the fix at September 22. That is a two-month window in which a critical, unauthenticated vulnerability in a security vendor's own management infrastructure was being used against at least some customers, described by the company only as 'targeted attacks' and later as affecting 'a handful of customers.' Check Point has not named the victims, the attackers, or what happened after initial access, which is a reasonable operational security posture during an active investigation but leaves every other customer of these products with a genuine open question: were we in that handful, and how would we know?
That gap is the real story, more than the CVSS score of 9.8. It shows how long a vulnerability can live in production before it becomes a public advisory, even when the vendor discovering it is a security company whose entire business is finding this class of flaw faster than everyone else. If it took Check Point two months to go from first observed exploitation to patch and disclosure on its own product, the honest assumption for any enterprise security tool in your stack is that a similar gap is plausible there too.
What to actually do about it this week
If you run Check Point Security Management Server, Multi-Domain Security Management Server, Log Server, or SmartEvent, treat the hotfix with the same urgency as the Citrix NetScaler patch making headlines the same week, not as routine maintenance to schedule for next sprint. Beyond patching, pull management-server access logs back to July 23 and look specifically for anomalous file or script uploads to the web service, unexplained configuration changes, and any gaps in your own log retention that would prevent that review from being conclusive. Check Point published temporary mitigations, including firewall hardening and IP allowlisting for the management interface, which should already be standard practice for a system this sensitive regardless of this specific CVE.
Just as important, permanently close any exposure if your management console has ever been reachable from anything broader than a tightly scoped management network, well beyond what this one CVE requires. Security management planes belong on isolated, tightly controlled network segments at all times. If yours currently sits somewhere more exposed, for convenience or because of a remote-office topology, this incident is the argument you use internally to fund fixing that architecture before the next advisory forces the issue.
Vendor risk now has to include the security vendor itself
Enterprises spend real budget on vendor risk assessments for SaaS tools, cloud providers, and business applications, and comparatively little scrutiny on the security vendors themselves, on the assumption that the company selling you protection has already solved this problem internally. Check Point's own management server joins a growing list this year of security and networking vendors, including Citrix and F5, whose products have been the source of significant zero-day exploitation rather than the shield against it. That pattern is now common enough to plan around rather than treat as bad luck.
Practically, that means adding your security stack, firewalls, management consoles, EDR platforms, and SIEM tooling, to the same vendor risk review cycle you apply to any other critical vendor, with specific questions about disclosure timelines, patch SLAs, and what telemetry you would have if that vendor's own infrastructure were the thing compromised. The assumption that your security vendor is inherently safer than your business applications is exactly the assumption this incident should retire.
The roadmap implication
Short term, patch the affected Check Point products this week, review logs back to July 23, and lock down any management-plane exposure you find along the way. That work is straightforward, time-boxed, and should already be moving through your change process by the time you finish reading this. The harder, longer-term work is building a monitoring capability that does not depend entirely on the vendor to tell you when their own product has been silently exploited for months, since this incident shows that notice can arrive well after the fact.
That likely means independent logging and anomaly detection around your security management consoles themselves, treated as a monitored asset rather than a trusted black box, plus a vendor risk process that explicitly scores security vendors on their own incident history and disclosure speed. The goal here is a healthy dose of skepticism applied evenly, extending the same scrutiny to the control tower that you already apply everywhere else, so a repeat of this exact failure mode gets caught internally well before a vendor advisory has to tell you about it.
