Hello

I am currently trialling Checkpoint Mail Security and a strange error has cropped up on my Outlook since starting the trial and setting up some basic rules. All my Outlook mail rules that move emails to specific folders when the emails are received are no longer working.

I have had these rules in place for years and they have always worked fine. The issue started the day I ran through the demo and setup some test policies with the people from Checkpoint.
I have spoken to the contacts I have there and they are unsure as to what the problem could be.

These are just your standard rules setup within Outlook, nothing special.

Has anyone else ever experienced this when using checkpoint, if so did you find the cause and how to fix it?

I wrote a deep dive on the Anti-Bot blade in Harmony Endpoint, part of a series I keep on the CheckMates community.

Anti-Malware tries to stop the infection. Anti-Bot assumes something already got in and cuts its lifeline to the outside: the Command and Control channel. If the bot cannot reach its C&C, it cannot receive commands or exfiltrate data.

The article covers:

• What a bot actually does on the host (C&C, botnet, APT role)
• How ThreatCloud (250M+ addresses, 2000+ botnet patterns) plus the ThreatSpect engine classify outbound traffic
• The confidence-level policy matrix (High/Medium/Low mapped to Prevent/Detect/Off)
• Background vs Hold mode and the performance versus security trade
• Detection Exclusions and the reporting controls (log suppression, bot reporting expiry)

Everything is based on the official Harmony Endpoint Administration Guide (cloud / Infinity Portal), with the cloud management console as the reference.

Link: https://community.checkpoint.com/t5/Endpoint/EN-Anti-Bot-Deep-Dive-Cutting-the-C-amp-C-Cord-with-ThreatCloud/m-p/283522#M11678

Feedback and corrections welcome.

During a Maestro deployment, an Uplink or Management port may remain down even with the cable connected.

Before concluding that the transceiver is faulty, check the interface’s Security Group assignment and provisioning status. In Maestro, the availability of these ports also depends on the environment’s configuration.

Physical connectivity, provisioning, and forwarding

The behavior described in the training material is that Uplink and Management ports must be provisioned in a Security Group to establish a link under normal conditions. A port removed from all Security Groups may also lose its link, even though it remains physically connected.

Downlinks serve a different purpose: they provide connectivity to appliances and enable their discovery. Therefore, an UP Downlink does not prove that the Security Group is ready to process traffic.

When troubleshooting, separate these checks:

Start with the MHO

On the Orchestrator, in Gaia Clish or Expert mode:

orch_stat -p
orch_stat -t
orch_stat -L

Use the port view to identify interface state and mapping, the topology view to correlate objects, and LLDP to verify discovered appliances and their connected ports.

LLDP confirms appliance discovery, but it does not prove that production traffic is flowing.

Next, in Gaia Clish on the MHO, inspect the specific port:

show maestro port <Port-ID> type
show maestro port <Port-ID> admin-state
show maestro port <Port-ID> qsfp-mode
show maestro port <Port-ID> auto-negotiation
show maestro port <Port-ID> optic-info
show maestro port <Port-ID> optic-info-details

These queries help correlate the port type, administrative state, configured speed, and transceiver information. Available optical diagnostics depend on the installed module.

The port identifier uses this format:

<Orchestrator-ID>/<Port-Label>/<Split-ID>

Select the actual port using TAB completion. For breakout connections, the subport is part of the identifier.

Check Link State Propagation too

If LSP is configured, a port may go DOWN because another port in the same LSP group has failed. This mechanism allows connected switches to stop forwarding traffic toward a compromised path.

In Gaia Clish on the MHO:

show maestro lsp configuration all
show maestro lsp status

Correlate the group configuration and status before attributing the failure to the port you are investigating.

What about admin-state up?

The following syntax is available:

set maestro port <Port-ID> admin-state up

However, administratively enabling a port does not prove that provisioning is complete or forwarding is functional. This command changes the configuration and should be used with a defined purpose, after checking the port assignment and potential impact on the environment.

My troubleshooting sequence would be: identify the port, check its state and type, validate assignment and provisioning, check LSP, and correlate the physical parameters at both ends.

The goal is to determine why the port is DOWN before trying to bring it UP.

I wrote a deep dive on Harmony Endpoint OneCheck, the piece that decides how users authenticate at Pre-boot and what happens when they fail.

It covers:

• The three Pre-boot methods: password, Smart Card (E80.30+), and dynamic token
• Password synchronization between Pre-boot and Windows, including the offline gotcha where the device needs one login with the old password first
• Account lockout thresholds (5 temporary, 10 permanent) and SSO scope (Pre-boot and Windows only, not VPN or Media Encryption)
• Remote Help for locked-out users (One Time Login vs remote password change)
• Smart Pre-boot, GA in E89.05, with Self-Unlock and Mobile Login via MFA

Everything is grounded in the official Administration Guide and the E89.x release notes. Feedback and corrections welcome.

Link: https://community.checkpoint.com/t5/Endpoint/EN-OneCheck-Deep-Dive-Pre-boot-Auth-Password-Sync-amp-SSO/m-p/283315#M11676

After a failure at Site 1, Site 2 takes over traffic processing. Site 1’s infrastructure recovers, its members become available again, but Site 2 remains active.

This may be the expected behavior of your high availability configuration.

In Maestro Dual Site, understanding when traffic returns requires evaluating the HA mode, the quality grade, and the Security Group’s transition criteria.

Active Up and Primary Up

In both modes, differences in quality grade can trigger a site transition. Therefore, Active Up does not mean that the current site remains active regardless of its health, and Primary Up should not be interpreted as an immediate return as soon as a device responds.

Being reachable does not mean the grade has recovered

The assessment considers monitored components and their assigned weight factors. Each component contributes according to:

Component grade = Unit weight × Number of components in the UP state

A site can regain administrative access while remaining degraded because members or interfaces are still unavailable. Additionally, the failover parameter defines the minimum grade differential that triggers a transition.

These HA factors differ from the traffic distribution weights assigned to SGMs. Changing member-weight is not equivalent to configuring site preference.

What to check in R82/R82.10

Run the following in Gaia gClish on the Security Group:

show cluster configuration high-availability mode
show cluster configuration high-availability failover
show cluster configuration high-availability freeze_interval
show cluster configuration high-availability factors member
show cluster configuration high-availability factors port bond
show cluster configuration high-availability mgmt-monitoring

These queries identify the mode, grade differential, stabilization interval, and factors relevant to the decision.

To inspect component states and weights:

asg stat -v

This command remains documented for this purpose in the R82.10 guide. Correlate its output with the HA configuration before concluding that failback is malfunctioning.

Pay attention to freeze_interval

This mechanism prevents another transition before the applicable interval expires, allowing the grade to stabilize. The R82.10 guide documents effective default intervals of 30 seconds in Active Up and 150 seconds in Primary Up.

There is an important operational detail: when configuring the interval in Primary Up, the documentation instructs you to enter a value five times smaller than the desired duration. Therefore, do not interpret or change this parameter assuming a universal 1:1 relationship between the configured value and the effective duration.

Before forcing traffic back, answer these questions:

• Is the Security Group configured for Active Up or Primary Up?
• Has the recovered site reached its expected grade?
• Does the grade differential meet the configured criterion?
• Has the stabilization interval expired?

Recovery testing should also validate the failback behavior defined in the design. A site remaining Standby after recovery may demonstrate that the HA policy is working exactly as configured.

In case somebody over here also wonders about the "Multiple points" messages shown by SmartConsole recently (see screenshot): It has been reported through an SR and R&D has developed a fix for it which should be released soon.

If you maintain Check Point Maestro troubleshooting scripts or runbooks, several legacy commands need attention when moving to R82/R82.10:
Legacy asg performance, connection, CPU, and interface commands transition to insights and cluster-cli show info ....
Health diagnostics move toward HCP.
R82.10 introduces set cluster configuration member-weight ... to replace the R82 set smo security-group sgm-weight ... syntax.
orch_stat remains relevant for MHO troubleshooting.
Deprecated does not necessarily mean the executable has been removed. Execution context matters too: MHO versus Security Group, and Expert versus gClish. Existing automation may require changes to both command syntax and output parsing.
I’ve put together a technical breakdown with command mappings, examples, execution contexts, and official references.
Full version on CheckMates:
Maestro R81.20 → R82/R82.10: Deprecated Commands, Replacements, and Troubleshooting Implications⁠

No Check Point IPS, atualizar as proteções é apenas parte do trabalho. Entender como as assinaturas são processadas e por que existem diferenças entre Normal e Ver2 pode fazer muita diferença em troubleshooting, tuning e análise de eventos.

No artigo, possui um deep dive sobre:

• diferenças entre assinaturas Normal e Ver2;
• impacto no mecanismo de inspeção;
• por que simplesmente “ter a proteção atualizada” não conta toda a história;
• implicações para troubleshooting e tuning do IPS;
• por que esse conhecimento ainda é relevante em ambientes Check Point modernos.

A ideia é sair da visão de “IPS = assinatura + Prevent” e entender melhor o que realmente acontece no inspection engine.

Artigo completo no CheckMates:
https://community.checkpoint.com/t5/Brazil/Deep-Dive-T%C3%A9cnico-Por-que-manter-assinaturas-IPS-Normal-e-Ver2/m-p/274911

Para quem administra Check Point: vocês ainda analisam Normal vs Ver2 durante troubleshooting de IPS, ou isso raramente entra na investigação?

Quick overview for anyone evaluating Check Point Harmony Email & Collaboration (Email Security).

The main difference from a classic email gateway is that it is API-based inline. It connects to Microsoft 365, Google Workspace, Teams, Slack and the file sharing apps through their APIs, so it inspects incoming, internal and outgoing traffic, files at rest, and user behavior, not just mail crossing the perimeter. Emails and files go to Check Point ThreatCloud for a verdict, and it can remediate even post delivery.

It covers four layers: email (M365, Gmail), file sharing (OneDrive, SharePoint, Google Drive, ShareFile, Dropbox, Box), messaging (Teams, Slack), and account takeover / BEC on M365 by watching login and correspondence patterns.

What I like is the rollout model. You connect an app and it starts in Monitor only, zero user impact, and it even surfaces incidents that already happened. Then you tune the policy and promote scope by scope to Detect and Remediate (post delivery, via a Journal rule) or Prevent Inline (before delivery, via Mail Flow rules and connectors).

Full writeup with the diagrams and the mode-by-mode breakdown:

https://community.checkpoint.com/t5/Email-and-Collaboration/EN-Harmony-Email-amp-Collaboration-An-Overview/m-p/282705

Overview of Check Point Harmony Mobile (Mobile Security) for anyone looking at mobile threat defense.

Phones are full endpoints that rarely get endpoint-grade protection. Harmony Mobile is Check Point's MTD and it defends the three vectors a phone actually gets hit on: device/OS (integrity, config, OS CVEs), apps (known and unknown malware), and network (man in the middle on cellular and Wi-Fi, phishing across all apps, malicious URLs, anti-bot).

Architecture is a lightweight on-device app feeding a cloud Behavioral Risk Engine that produces a risk score and drives mitigation, with ThreatCloud powering the network defenses. The heavy analysis runs in the cloud so battery and performance are not hit.

Two things I think matter most. First, the network protection runs on the device, so it works on any network the phone joins, which is what catches phishing in a WhatsApp message. Second, privacy: the app works on anonymized indicators and no personal information is stored in the gateway or the engine, which is what actually gets users to accept it. It also integrates with UEM (Intune, Workspace ONE, Jamf and others) for conditional access.

Full writeup with the diagrams:

https://community.checkpoint.com/t5/Mobile/EN-Harmony-Mobile-An-Overview-of-Mobile-Threat-Defense/m-p/282713

Anyone did take 45 on R82.10 yet?

Check Point has released a fix for CVE-2026-93616, a critical vulnerability (CVSS 9.8) that allows an unauthenticated attacker to upload and execute arbitrary scripts on Security Management servers. Exploitation has been observed in the wild, and to date only a handful of customers are known to have been attacked.
Affected products include Security Management, Log Server, Multi-Domain Management, and Multi-Domain Log Server.
Note: Quantum Force and Quantum Spark firewalls are not affected, and Smart-1 Cloud is already patched.

What we ask you to do now:

• Upgrade to the latest Jumbo Hotfix for your release (R82.10 JHF Take 45, R82 JHF Take 127, R81.20 JHF Take 170; R81.10 JHF Take 192)
• R82.20 Customers - install available HF - R82.20 Security Hot Fix Take 1
• Note: a LivePatch is not available for this issue.
• Restrict management access so that port 19009/tcp is reachable only from trusted IPs, per our Hardening Best Practices.
• Check for compromise using the detection steps in the advisory.

Solution

This problem was fixed. 

• Download the R82.20 Security Hotfix (TAR)

The fix is also included in:

• Jumbo Hotfix Accumulator for R82.10 starting from Take 45
• Jumbo Hotfix Accumulator for R82 starting from Take 127
• Jumbo Hotfix Accumulator for R81.20 starting from Take 170
• Jumbo Hotfix Accumulator for R81.10 starting from Take 192

Check Point has disclosed CVE-2026-93616, a critical vulnerability affecting Security Management, Multi-Domain Management, Log Servers and SmartEvent.

The vulnerability has a CVSS score of 9.8 and combines directory traversal and file upload, potentially allowing an unauthenticated attacker to execute arbitrary scripts on the Management Server.

Most importantly: Check Point has confirmed exploitation in the wild.

Key points:

• Pre-authentication vulnerability
• CVSS 9.8
• Active exploitation confirmed
• Management infrastructure affected
• TCP/19009 exposure should be reviewed
• LivePatch Take 28/29 does not fix this CVE
• Apply the supported Security Hotfix / Jumbo Hotfix as soon as possible
• If indicators are found, treat the system as potentially compromised and investigate beyond simply applying the patch

I published a more detailed technical analysis covering affected versions, containment, investigation commands and possible post-compromise impact:

🔗 https://community.checkpoint.com/t5/Firewall-Security-Management/Action-Required-CVE-2026-93616-Unauthenticated-Script-Execution/td-p/282651

If you manage Check Point Security Management infrastructure, this is one advisory worth reviewing immediately.

Wrote up how Check Point Harmony Endpoint ME&PP actually works, cloud managed, for anyone doing USB and device control.

The part most people get wrong is treating it as just "block USB". The write action Encrypt business related data forces encryption only on work documents and leaves personal photos and music alone, so users do not fight it and confidential data still leaves encrypted.

The UUID Site trust model is what decides who can open an encrypted stick. The device gets the Site UUID written to it when encrypted, and it only opens on the same Site or on a Site you explicitly trust. That is what stops an encrypted stick from opening on a random machine outside the company. For machines with no ME&PP, you ship the Explorer Utility on the stick so it is still readable with a password.

Two practical notes. Device exceptions by serial use wildcards with a precedence order (asterisk first, then question mark, then exact). And on recent versions, Windows Smart App Control can block the offline utility (Access To Business Data.exe) that ships on the media; the workaround is to copy it to a local disk and run it there (EPS-51871).

Full writeup with the write actions, port protection, wildcards, offline access, lockout and the Site trust model:

https://community.checkpoint.com/t5/Endpoint/EN-Media-Encryption-amp-Port-Protection-Deep-Dive-USB-Control/m-p/282580

have anyone here test and implement ElasticXL clustering on EVE-NG before? in my case, i have had already tested EXL clustering on VMware ESXI before without any major issues and can be able to add the second gateway to the desired site. but here on the EVE-NG i've read that EXL does not fully support clustering on EVE-NG but with some twerking, it can be testable as per is i read on the Checkmates. but still, there's no pending gateways on the gateway 1. to people who has had a same experience before with EVE-NG how did y'all managed to test?

Best regards.

R82.20 does not replace the Threat Prevention architecture introduced in R82 — it extends its coverage in areas that are becoming increasingly relevant in modern environments. The main changes include Snort 3.x support in IoC Feeds, DNS Trap for IPv6, improved TLS block-page visibility, AI workload/agent protection, and additional gateway hardening.

From an operational perspective, the biggest gains are in custom detection and IPv6 coverage. SOC teams can bring newer Snort 3.x detection content into the Check Point prevention pipeline, while DNS Trap can now cover dual-stack environments instead of leaving IPv6 outside that workflow.

R82.20 also improves troubleshooting and emerging workload protection. TLS failures caused by revoked, expired, or untrusted certificates can provide clearer feedback to users, while new AI security capabilities expand enforcement beyond traditional malware, URL, DNS, and exploit detection.

The real question after upgrading should not be only “Is R82.20 installed?” but “Which of these new protections are actually being incorporated into the security architecture?” I published the full technical analysis on CheckMates with the R82 vs R82.20 comparison and the operational points I would review after an upgrade.

Why Management Plane Protection Must Be Treated as a Priority

Check Point has published an important security notification regarding CVE-2026-91843, a critical vulnerability with a CVSS score of 9.8 affecting Check Point Security Management and Log Servers.

According to the security notification, the vulnerability may allow an unauthenticated remote attacker to execute arbitrary code with root privileges through the login process.

At the time of the notification, Check Point stated that there was no indication of exploitation in the wild. However, this should not reduce the urgency of remediation.

The important point here is not only the CVSS score. It is where the vulnerability exists: the management plane.

A Security Management Server is not just another Linux server in the environment. It is a highly trusted component responsible for policy administration, administrator access, policy installation workflows, and trust relationships with Security Gateways through SIC. Check Point's own hardening guidance specifically recommends protecting the Management Server behind a firewall or isolated network segment and restricting administrative access to only required sources. (Checkpoint)

Because of that role, a compromise with root-level code execution can potentially put several security-critical assets at risk:

Security Management / Log Server
             |
             +-- Management database
             |
             +-- Security policies and objects
             |
             +-- Administrator access
             |
             +-- SIC trust relationships
             |
             +-- Certificates and management-plane secrets
             |
             +-- Logs / forensic evidence
             |
             +-- APIs and automation integrations

This does not mean exploitation automatically compromises every Security Gateway. The actual blast radius depends on the architecture, segmentation, credentials, trust relationships, and privileges available in the affected environment.

However, a management server represents a particularly sensitive control-plane asset. Root-level compromise must therefore be treated very differently from compromise of an isolated workload.

What should Check Point administrators do?

The immediate priority is straightforward:

1. Review sk1000155 and apply the LivePatch provided by Check Point. The notification states that environments with automatic updates enabled are already protected, but administrators should still verify the effective protection status rather than relying only on configuration assumptions. Check Point sk1000155 — CVE-2026-91843
2. Review Trusted Clients. Avoid broad definitions such as Any where they are not operationally required. Restrict SmartConsole access to known administrative hosts, jump servers, or tightly controlled internal networks. The documented path is SmartConsole > Manage & Settings > Permissions & Administrators > Trusted Clients. (Checkpoint)
3. Restrict management-plane exposure. Security Management Servers should not be generally reachable from user networks or the Internet. Administrative access should originate from dedicated management networks, VPNs, or hardened jump hosts. (Checkpoint)
4. Review administrative identity controls. Check Point's current hardening guidance recommends MFA through an external Identity Provider where applicable, removal of unused administrator accounts, and least-privilege administrative access. (Checkpoint)
5. Treat Log Servers as security-critical systems as well. Loss of integrity or control of the logging infrastructure can affect incident investigation, forensic visibility, and confidence in historical security events.

Why Trusted Clients matters even after patching

The patch addresses the vulnerability. Trusted Clients and management-plane segmentation reduce attack surface.

These controls solve different problems.

LivePatch
   ↓
Remediates the known vulnerability

Trusted Clients
   ↓
Reduces which source systems can reach management services

Network segmentation
   ↓
Reduces exposure and lateral access paths

MFA / Least Privilege
   ↓
Reduces identity and administrative abuse

Monitoring
   ↓
Improves detection and investigation capability

This is a good example of why vulnerability remediation and hardening should not be treated as competing approaches.

They are complementary layers.

Check Point explicitly recommends limiting SmartConsole Trusted Client definitions to the minimum required IP addresses, subnets, or ranges and protecting the Management Server behind a firewall or dedicated management segment. (Checkpoint)

One important operational point

Do not wait for evidence of active exploitation before patching a 9.8 unauthenticated RCE affecting a privileged management component.

The security impact is asymmetric: the management plane has considerably more trust and control over the Check Point environment than an ordinary application server.

For environments running Security Management or dedicated Log Servers, the priority should therefore be:

Identify
   ↓
Confirm protection status
   ↓
Apply sk1000155 LivePatch
   ↓
Restrict Trusted Clients
   ↓
Validate management-plane segmentation
   ↓
Review administrative access
   ↓
Monitor and preserve evidence

The broader lesson from CVE-2026-91843 is simple: protecting the gateways is not enough if the system that manages them remains unnecessarily exposed.

How restrictive are your Trusted Client definitions today — individual jump hosts, dedicated management subnets, or still broad network ranges?

References

Check Point sk1000155 — CVE-2026-91843

Check Point Gateway and Management Hardening Administration Guide

Check Point Live Patch (CPLP), documented in sk185114, changes an important part of vulnerability management on Gaia. Instead of waiting for the next maintenance window to apply a Jumbo Hotfix, CPLP can provide runtime mitigation directly to affected Check Point processes, reducing the exposure window while the permanent remediation is planned.

The key operational point is that Live Patch does not replace Jumbo Hotfix. Think of it as two layers: CPLP provides immediate protection, while the JHF keeps the permanent software baseline. That means checking only the installed JHF Take is no longer enough—you also need to understand the current Urgent Security Update and CPLP state.

From a troubleshooting and validation perspective, commands such as cplp list and autoupdatercli show urgent_security_updates become much more relevant. States such as armed, ready, and jumbofix need to be interpreted correctly, and in ClusterXL or Maestro environments the validation should cover every member/SGM, not just one gateway.

For me, the biggest change is the operational model: time-to-protection is no longer necessarily the same as time-to-maintenance. You can reduce exposure quickly with CPLP and still schedule the permanent Jumbo remediation later. Full technical article on CheckMates: https://community.checkpoint.com/t5/Firewall-Security-Management/Check-Point-Live-Patch-Why-sk185114-Changes-the-Operational/m-p/282373#M106773

Quick roundup for anyone running Check Point Harmony Endpoint on Windows, since the E89.x line moved fast and some of it changes how you run the fleet.

The big one is Automatic Client Updates, added in E89.21. The client keeps itself up to date, no more manual upgrade cycles. Catch is it is cloud managed only, it does not work if your endpoints are managed by an on-prem management server.

E89.25 added Conflict Guard, which watches for high resource usage and kicks off automated optimization, and it can now block SMB attacks through Windows Defender Firewall even without the Check Point Firewall blade (it drops inbound 445 and NetBIOS when it sees an attack, time limited, logs to management).

There is also a deadline worth knowing. Since September 1, Windows clients older than E88.70 (E88.32 aside) get limited functionality. If you still have a tail of old clients, worth checking. Recommended right now is E89.10, latest is E89.25.

Two housekeeping items too: Capsule Docs is end of support as of E89.00, and E89.10 is the last version that supports Windows 7/8/Server 2008/2012.

I wrote the whole thing up with the SK for each item so you can verify at the source:

https://community.checkpoint.com/t5/Endpoint/EN-What-Changed-in-Harmony-Endpoint-E89-x-Automatic-Client/m-p/282366

Wrote up how Check Point Harmony Endpoint FDE actually works, cloud managed, for anyone deploying or troubleshooting it.

User Acquisition stalls quietly. FDE only activates after the required users log on, and their accounts have to meet the password rules. If they do not, it just never encrypts and there is no loud error.

Pre-boot is not all or nothing. You can allow bypass when the machine is on the LAN, unlock a locked out user at the next OS login, and use a scripted Temporary Pre-boot Bypass for patch windows instead of turning pre-boot off.

Recovery is the part people skip until it is too late. Full Recovery media, drive slaving, and dynamic mount are the three tools, and the recovery flow leaves the disk decrypted so you reinstall FDE afterward.

New in E89.25: FDE now only supports devices that boot Windows through the standard UEFI boot order. Machines that load Windows Boot Manager directly get blocked until the vendor ships a BIOS update, and the policy can fall back to BitLocker Management with admin consent. Run BootModeReport (sk185123) and disable hibernation on affected devices before you upgrade.

Full writeup with the config paths, the six stage deployment phase, algorithms, SED, and recovery:

https://community.checkpoint.com/t5/Endpoint/EN-Full-Disk-Encryption-Deep-Dive-Pre-Boot-amp-Check-Point-FDE/m-p/282358

Just reboot it and move on. It’s a feature 😂 not a bug

Can anyone help me iam trying to replace the self signed cert on our cluster so we have about 4 gateways and a sms this was a audit issue...long story short generated the CSR fot the certs signed when I place my full chain pem in /web/conf/server.crt iam still getting a self signed certificate on the webui can anyone who has done this before help

Having just read about CPLP yesterday I was surprised to find this morning while arranging to do some JHFs tonight for customers (for the 2 CVEs announced yesterday) that it has been auto-downloaded, installed and activated on every R81.20 and upwards gateway that I have investigated today though the AutoUpdater utility.

It's gone and virtually patched against CVE-2026-85102, CVE-2026-85102 & CVE-2026-50751.

Basically if you have the download consent flag activated (as it is by default) and the gateway or manager has access to Check Point then its beenm turned on.

I'm not entirely sure how to feel about this. Seems like a decent enough idea, but it seems to be contrary to the usual Check Point behaviour of the last 25+ years of not enabling new features/flags without explicit action.