The Attack Landed July 23. Check Point Told You September 22.

Compromising a firewall gets you one firewall. Compromising the server that configures the firewalls gets you all of them, plus the ability to write your own rules on the way out. That’s the difference CVE-2026-93616 turns on, and it’s why a bug in a management appliance most people never log into deserves more attention than a bug in the appliances everyone stares at all day.

Check Point disclosed on September 22 that the flaw — unauthenticated script execution on its Security Management Servers, reachable through an exposed web service — had already been used in targeted attacks. A patch is available. Here’s what the numbers actually tell you.

61 days

That’s the gap between the exploitation Check Point cites — July 23 — and public disclosure on September 22. Two months where the bug was live, being used against real targets, and undocumented for everyone else running the same software.

I’m not going to pretend that’s unusual. Coordinated disclosure timelines routinely run this long, especially when a vendor is building and testing a fix for infrastructure that customers are terrified to reboot. But it changes what “patch now” means for you. This is not a theoretical CVE that researchers found in a lab and responsibly reported before anyone weaponised it. Someone shipped a working exploit against production management servers before you knew the door existed. Your logs for late July are the interesting reading, not your logs for this week.

If you retain firewall and management logs that far back, that’s the window to hunt in first.

Zero

The number of credentials the attacker needed. “Unauthenticated” is the word doing all the work in this advisory, and it’s the reason this isn’t a next-cycle item.

Most management-plane bugs assume the attacker already has a foothold — a stolen admin session, a valid API token, something. This one doesn’t. Reachability is the whole precondition. If the management server’s web service can accept a connection from where the attacker sits, they can run scripts on it without ever proving who they are. There’s no password to brute-force, no MFA prompt to phish, no session to hijack. The request itself is the exploit.

That collapses the attack chain to a single question: who can reach the web service on your Security Management Server? If the honest answer is “more networks than I’d like to admit,” you’re exposed. If it’s “a tightly scoped management VLAN and nothing else,” you’ve bought yourself time — but not a pass.

One box to write every rule

Think of the Security Management Server as the locksmith, not the lock. Your gateways are the locks on the doors — they enforce policy, but they don’t decide it. The management server is the shop out back where every key gets cut, where the master template lives, and where the record of which key opens which door is kept. Break into the locksmith’s shop and you don’t need to pick a single lock. You cut yourself a key, or you quietly re-cut someone else’s.

Concretely, code execution on a management server hands an attacker:

• Policy authorship. They can push new firewall and VPN rules to every managed gateway — open a path, whitelist an IP, disable an inspection blade — and it looks like a legitimate policy install because it is one.
• Credential and certificate material. Management servers hold the trust that binds gateways to the manager. That’s a launchpad for impersonation and for trusting rogue components.
• A pivot into everything the management plane touches. Every gateway it administers is now downstream of a compromised authority.

That’s the blast radius. Note the restraint here: this hits organisations running Check Point Security Management Servers reachable by an attacker. It is not “every Check Point customer,” and Check Point’s own framing is a targeted-attack story, not a mass-scan-and-spray one. Don’t let anyone sell you the panicked version.

Which versions, honestly

Check Point’s advisory is the authoritative source for the exact affected releases and the specific fix, and you should pull the version and hotfix takes straight from it rather than from any summary — including this one. I’m not going to quote build numbers I can’t verify, because a wrong patch take is worse than no patch take: it convinces you you’re safe when you aren’t.

What I can tell you is the shape of it. The exposure is tied to the management server’s web service, so any deployment where that service is running and reachable is in scope until proven patched. Standalone gateways that don’t host the management role are a different conversation. Match your own inventory against the advisory’s version list before you decide you’re unaffected — “we run Check Point” is not a risk assessment.

Three read-only commands

Before you touch anything, establish where you stand. All of these are diagnostic — they read state, they don’t change it. Run them on the Security Management Server itself, in expert mode.

1
2
3
4
5
6
7
8

# 1. Product version and build — the baseline the advisory maps to
clish -c "show version all"
​
# 2. Every installed hotfix and jumbo take, so you can match against the fix
cpinfo -y all | less
​
# 3. The current jumbo hotfix accumulator take on this box
installed_jumbo_take

Cross-reference the output of these against the specific fixed version and hotfix take named in Check Point’s advisory. If your take is at or above the one that carries the fix, you’re patched. If it isn’t, you’re not — regardless of how recently you think you updated.

Separately, answer the reachability question from the network side. From a host that sits outside your intended management boundary, check whether the management web services actually answer — a read-only probe, no exploitation:

1
2
3
4
5
6
7

# Run from a vantage point that SHOULD NOT reach the mgmt server.
# Replace ports with those your deployment actually exposes for
# Gaia Portal / management API / SmartConsole services.
nmap -Pn -sT -p 443,4434,18190,19009 mgmt.internal.example
​
# A closed/filtered result from an untrusted segment is what you want.
# An open result means the exploit precondition is met from there.

The second check matters more than the first for prioritisation. A vulnerable-but-unreachable box is a manageable problem. A vulnerable-and-internet-adjacent box is an incident waiting for a timestamp.

The order of operations

Patch, but sequence it against exposure:

1. Apply the hotfix Check Point published with the September 22 advisory. That’s the real fix; everything else is a stopgap. Take the exact take number from the advisory and verify it landed with installed_jumbo_take afterward.
2. If you can’t patch in the same maintenance window, choke the reachability. The whole attack depends on getting a packet to the web service. Restrict access to the management interfaces to a dedicated administration network — jump hosts and known admin ranges only — and drop everything else at the perimeter and at the Gaia firewall on the box itself. This doesn’t fix the bug. It removes the attacker’s line of sight to it, which for an unauthenticated flaw is most of the battle.
3. Then go back to July. Once you’re patched and scoped, treat any management server that was internet-reachable before this as possibly-touched until you’ve reviewed it. Look for unexpected policy installs, new or modified rules, unfamiliar administrator activity, and script or process execution on the management server around and after July 23. Because the malicious activity runs through legitimate management channels, “no alerts fired” is not the same as “nothing happened.”

Immediate, or this week — pick by exposure

If your management server’s web service is reachable from the internet or from any network segment you don’t fully trust: this is an immediate action. Unauthenticated, in-the-wild, remote code execution on the control plane is the exact profile you drop other work for. There’s no compensating control that beats “the attacker can’t reach it” plus “the bug is patched,” so do both, today.

If your management plane is genuinely isolated — segmented admin network, no external reachability, tight ACLs you’ve actually verified rather than assumed — you can run this on a this-week footing: patch in your next controlled window, but verify the isolation is real before you relax. An insider path or a compromised jump host turns “isolated” into “exposed” without changing a single firewall rule you can see.

The uncomfortable version, stated plainly: the box you use to enforce security policy across your network was, for two months, a place an attacker could run code without a password. The patch closes that. Whether it closed it before or after someone walked through is the question your July logs answer — so read them before you decide this one’s over.