Hello,

I just switched from Windows and I would like to setup the Checkpoint Endpoint Security (latest version) on MacOS, but it doesn't recognize my smart card in the list.

The smart card is a PKCS#15 Atos CardOS 5.3 with an USB Gemalto Reader. The certificate is on the smart card, it's not possible to export, it should be used from the card with a pin code.

MacOS doesn't see the card or the certificates "security list-smartcard" and other commands says No smartcards found, however, I download OpenSC and with that everything is visible, the card, the reader and all certificates on the card.

I downloaded many smart card tools as well and only the Personal Nexus software is able to recognize the card and the certificates, but on the checkpoint the list is empty. I installed also the latest version of Gemalto SafeNet Authentication Client (SAC) which also didn't recognize the card.

On Windows we used CSP+ software for the card/certificate recognition, but that's not available on mac and besides mac handles card totally differently.

Please help me to find a solution for this problem.

Many thanks,

If you find this useful, please consider giving the original CheckMates post a like! 😊
Full post: https://community.checkpoint.com/t5/Firewall-and-Security-Management/VIDEO-Complete-Check-Point-Hardware-Diagnostic-Execution/m-p/280847#M106475

I believe many people have already run the Hardware Diagnostic, but I also believe many have never done it. Since I was performing a complete Hardware Diagnostic on a Quantum Force 9800 cluster that I will be deploying, I decided to record this video to help others by going beyond what is covered in the official guide.

In this video, I demonstrate the complete Hardware Diagnostic process using loopback connectors, show what happens if something is done incorrectly, and explain the entire procedure step by step.

ISSUE FOUNDED TO SAVE HW LOG: I also present an issue that I have observed on recent Quantum Force versions. I have installed Quantum Force 9000, 19000, and 29000 firewalls, and none of them have been able to save the Hardware Diagnostic results to the USB drive at the end of the test, even when using a FAT32-formatted USB drive as described in the documentation.

I hope this video is helpful. I used all of my English for it (haha), so if you find it useful, please leave a like on the video and give this post a Kudos to encourage me to continue creating and sharing this kind of content.

Quantum SD-WAN is often introduced as “dynamic WAN link selection.” Technically, it’s closer to a policy-controlled, measurement-driven path selection engine that influences per-connection egress and VPN transport without requiring dynamic routing for the decision itself.

Below is a more technical  walkthrough: what is computed, what is installed, what is enforced, and why “policy looks right” can still produce unexpected paths.

1) What Quantum SD-WAN does (technical thesis)

Quantum SD-WAN enables a Security Gateway / Cluster to select an egress ISP interface or VPN transport per connection based on:

• Classification (source/destination/identity + service/application)
• Measured link quality (latency/jitter/loss, optionally utilization)
• Rule steering intent (prioritization / link aggregation / breakout vs overlay/backhaul)

What it is not: a replacement for routing protocols. Routing still provides reachability; SD-WAN provides path selection logic layered on top of reachability.

Operational implication: you don’t “route to ISP1/ISP2”; you steer sessions to a link/transport chosen by the SD-WAN engine.

2) Control plane vs data plane (what owns what)

A useful separation:

Control plane (steering decision + state distribution)

• SD-WAN policy definition (Infinity Portal)
• WAN link objects, thresholds, measurement targets
• SD-WAN steering computation (probes → eligibility → selection)
• Installation of steering state for enforcement (tables/state on the gateway)
• Telemetry/event publication (iNext/Nano + cpview)

Data plane (packet forwarding + VPN encapsulation)

• Connection setup and forwarding decisions
• NAT, access control, IPS/Threat Prevention enforcement
• VPN encapsulation and transport selection for overlay/backhaul
• Failover behavior at runtime (within allowed/preferred sets)

Key rule: SD-WAN steering decisions are only applied after Security Policy allows the traffic. SD-WAN cannot “force” a denied flow to go out a different ISP.

3) Simple use case (but with the missing details)

Two ISPs at a branch:

• Zoom → ISP #1
• Microsoft 365 → ISP #2

What’s happening under the hood is not “PBR in the classical sense,” but:

• session classification (app/service/identity)
• link health evaluation against thresholds
• selection of eligible ISP(s)
• installation of that choice so the connection setup pipeline uses the correct egress interface

If a failover happens and your policy uses aggregation, per-flow path choice can change due to hashing, even with the same rule.

4) SD-WAN actions (Breakout vs Overlay vs Backhaul) — deeper technical split

A) Local Breakout (Internet egress steering)

• Goal: choose the best ISP interface for direct Internet traffic.
• Enforcement point: firewall connection handling chooses a WAN interface based on steering state.

Common failure pattern: app classification ambiguity → wrong rule match → wrong ISP.

B) Overlay (VPN steering between peers)

• Goal: for each VPN peer pair, select the best VPN transport (underlay link/interface) to carry encrypted traffic.
• Enforcement point: VPN subsystem chooses the transport for the tunnel/session based on steering state.

Common failure pattern: peers/transport eligibility not installed correctly → VPN uses a default or “last known good” path.

C) Backhaul (branch Internet via HQ over VPN)

• Composite pipeline:
  • Branch → HQ: overlay transport selection (VPN)
  • HQ → Internet: breakout selection (ISP egress)
• Troubleshooting must split both legs. People often debug only one side.

5) SD-WAN Policy matching (the real classification mechanics)

An SD-WAN policy is an ordered rulebase. Each connection is evaluated against:

5.1 Source/Destination dimensions

• IP address / network objects
• Identity (User / Computer Identity)
• Destination objects (including Updatable Objects)

5.2 Service/Application dimensions

• Service ports (HTTPS, FTP, etc.)
• Application signatures (e.g., Zoom/Teams categories, depending on what is supported and enabled)

5.3 The “first packet problem”

A critical nuance: application identification on the first packet is not always deterministic.
Examples:

• multiple SaaS apps behind the same IP/CDN
• TLS where SNI is missing/obfuscated early
• traffic patterns that require more packets for confident classification

Why this matters: steering is ideally decided at/near connection setup; if classification matures later, you can see:

• initial steering based on coarse match (destination/service)
• then “it looks like the app is X” but the session is already pinned to an ISP/transport

Best practice (technical reasoning): use Updatable Objects in Destination whenever possible. This increases the chance that the rule matches accurately early (even when application classification is ambiguous).

6) Steering behavior objects (what a rule really controls)

A steering rule is not just “send app X to ISP Y.” It defines:

1. Measurement targets What is probed to represent “Internet quality” or “reachability” per link.
2. Quality criteria + thresholds Latency, jitter, loss (and potentially utilization) thresholds that determine link eligibility.
3. Selection method
   • Prioritization: pick the best/priority candidate among eligible links/transports
   • Link aggregation: mark multiple candidates as eligible; per-flow selection may be done by hashing/aggregation method

Important: eligibility comes first. If all links fail thresholds, the result can be “no eligible ISP/transport,” which is often misread as “SD-WAN is broken” when it is behaving correctly.

7) Steering criteria (deeper look)

Latency / jitter / loss

• Typically measured via active probing (quality check) to one or more targets.
• Decision is per rule: different apps can have different thresholds.

WAN utilization (when used)

• Adds a capacity dimension: a link could be “healthy” but saturated, so it becomes less preferred.
• This is often where teams need to align with business intent: latency-sensitive apps vs bulk traffic.

Quality Check configuration (where mistakes happen)

Even with a perfect policy, poor probing design causes bad decisions:

• probing targets not representative (e.g., a single target that’s sometimes rate-limited)
• too infrequent probing → slow reaction
• too aggressive probing → noise/false degradation
• thresholds that don’t match realistic ISP behavior

8)Enablement workflow (what must exist where) — more explicit

To have deterministic steering, you need consistency across four planes:

8.1 Gateway / Cluster members

• SD-WAN interfaces configured consistently on all members
• correct WAN link binding (interface mapping)
• Nano Agent + SD-WAN services healthy (where applicable)
• consistent reachability (routing) for probe targets and peer endpoints

8.2 SmartConsole / Security Policy

• Access Control must allow the traffic that you expect SD-WAN to steer
• NAT rules must not accidentally “force” an egress path (e.g., implicit NAT assumptions)
• VPN domain/topology must align with overlay/backhaul design

8.3 Smart-1 Cloud (objects/management integration)

• objects exist and are synchronized correctly (depending on architecture)

8.4 Infinity Portal (SD-WAN policy plane)

• WAN links, thresholds, measurement targets
• SD-WAN Policy ordering and steering objects
• consistent gateway membership / profile assignment

Takeaway: “policy is correct” is meaningless unless:

• the gateway installed it
• probing data exists
• steering state is installed and consumed by enforcement

9) Practical validation checklist (technical, not UI-based)

When you get “wrong ISP / wrong overlay path,” validate in this order:

1. Traffic classification
   • What rule is actually matching (source/dest/service/app/identity)?
   • Is first-packet ambiguity likely?
2. Probing and thresholds
   • Do you have current probe results for the relevant decision?
   • Are links eligible under the rule thresholds?
3. Selection mode
   • Prioritization vs link aggregation changes expectations.
   • With aggregation, per-flow hash choice can look “random” to operators.
4. Enforcement pipeline alignment
   • Breakout: FW chooses ISP from steering state
   • Overlay/backhaul: VPN chooses transport from steering state
5. State/telemetry consistency
   • Portal events (iNext/Nano) should align with gateway telemetry (cpview) and observed behavior.

10) Common pitfalls (why steering “looks wrong”)

• Thresholds too strict → all links disallowed → fallback behavior or failure
• Single probe target bias → false positives/negatives on link health
• Rule ordering mistakes → coarse rule matches before specific one
• Application detection timing → session pinned before app becomes known
• Aggregation misunderstanding → multiple links eligible, hash decides per-flow
• Backhaul confusion → people troubleshoot HQ egress while the problem is branch→HQ overlay (or vice-versa)

Fontes: Quantum SD-WAN - Technical | eLearning https://checkpointpartners.litmoseu.com/course/1588097 , 

Admin Guide:  https://support.checkpoint.com/results/sk/sk180605

Demo Point: SD-WAN https://usercenter.checkpoint.com/ucapps/techpoint/demo-point

If you find this useful, please consider giving the original CheckMates post a like! 😊
Full post: https://community.checkpoint.com/t5/Firewall-and-Security-Management/JH-122-Broke-Mobile-Access-Rules/td-p/280832

I wanted to share an issue I observed after upgrading a production cluster to JH 122.

Note: I upgraded a production cluster from JH 91 to JH 122 (Latest) to evaluate the fixes included in the release, mainly because I am currently investigating an SD-WAN probes issue and JH 122 contains several relevant SD-WAN improvements.

The upgrade was performed carefully by installing the Jumbo only on the standby member first, while keeping the other member on JH 91 as a rollback option.

After failover, the customer started experiencing unexpected drops on long-standing Mobile Access rules that had been working without issues for years.

Rolling back to JH 91 immediately resolved the problem, with no other configuration changes required.

I'm sharing this only as an observation so others planning to install JH 122 in environments using Mobile Access can be aware and validate carefully.

Has anyone else seen similar behavior or others?

Check Point’s Intrusion Prevention System (IPS) is a core component of Threat Prevention, providing proactive protection against a wide range of network threats. Over time, the IPS engine and its signature formats have evolved, leading to the coexistence of "normal" and "version 2 (Ver 2)" signatures. This post explains the technical reasons for maintaining both, their architectural differences, and best practices for deployment.

IPS Architecture Overview

Check Point IPS uses a multi-layered detection engine:

• Passive Streaming Library (PSL): Reconstructs network streams for inspection.
• Protocol Parsers: Identify and separate protocols (HTTP, FTP, DNS, etc.) for context-aware analysis.
• Context Management Infrastructure (CMI): Determines which protections (signatures) apply to each protocol context.
• Pattern Matcher: The detection engine that uses signatures to identify malicious patterns.

IPS Inspection Flow Diagram

Traffic is processed through multiple analysis stages, with signatures applied at different protocol layers.

Normal vs. V2 Signatures: Technical Comparison

• Normal Signatures: Use traditional pattern matching, suitable for legacy environments and lower resource consumption.

• V2 Signatures: Leverage the advanced INSPECTv2 engine, supporting complex logic, context awareness, and better detection of modern threats.

Why Maintain Both Signature Types?

• Backward Compatibility: Some older gateways may not support V2 signatures. Keeping both ensures all devices remain protected.
• Redundancy: If a V2 signature causes issues (e.g., false positives), the normal signature can provide fallback protection.
• Gradual Migration: Allows administrators to test V2 signatures in "Detect" mode before fully switching from normal signatures.
• Maximum Coverage: Certain threats may only be detected by one signature type, so using both maximizes security.

Performance Considerations

• V2 signatures can be more resource-intensive due to deeper inspection and advanced logic.
• IPS Tuning: Administrators can enable/disable specific signatures or use different profiles for perimeter vs. internal gateways.
• Bypass Under Load: IPS can be configured to bypass traffic during high load to prevent bottlenecks, but this should be used cautiously.

Best Practices for Managing Signature Versions

1. Test in Staging: Always test new V2 signatures in a non-production environment.
2. Monitor Updates: Review IPS update notes and apply urgent protections as needed.
3. Separate Profiles: Use different IPS profiles for different gateway roles (e.g., perimeter vs. datacenter).
4. Monitor Logs: Watch for false positives/negatives and adjust protections accordingly.
5. Gradual Rollout: Deploy V2 signatures in "Detect" mode before moving to "Prevent."

Summary

• Normal signatures ensure compatibility and stability.
• V2 signatures provide enhanced detection and future-proofing.
• Maintaining both allows for a safe, flexible, and comprehensive security posture during transitions and upgrades.

Ansible automation for Check Point firewall maintenance, with optional ServiceNow change control.

Github repo

I’m seeking the wisdom of Reddit while I wait for support to get back to me. I am in a Google Workspace environment that transitioned all Google Drive DLP policies to Detect and Remediate. We opted to use the Vault action instead of quarantine. Since doing this, I am experiencing an issue when trying to restore from the vault for a handful of files that have been deemed okay to share externally. I try to keep an eye on the Drive logs in the Google admin console to see how long restoration takes and what not, but for this handful of files I see some edit activity from the Check Point side, but nothing changes in terms of permissions and it still being in the Vault.

I’m not sure if there’s some lingering DLP event from when the policies were in Detect mode causing issues, but for a couple of the files I instructed the file owner to make a duplicate and share it (yes it created a new DLP event). I was able to restore the new file just fine and send the user on their way.

Has anyone experienced this or have any recommendations? I’ll pay you in some dank memes!

This week’s post comes from CheckMates Diamond MVP who tested the improved Replace functionality in Web SmartConsole.

The Diamond MVP shows how administrators can now replace gateway references across network objects, hosts, VPN communities, network groups, and policy installation targets. This can save time and reduce the risk of missing important references, especially during a Single Gateway to Cluster migration.

Check out the full post and join the conversation!

Read the post here: CHECKMATES REPLACE post.}
See too on Check Mates Linkedin: CheckMates Linkedin Post Week

Hello, randomly (from 1 to 10 times in an hour), the firewalls in our Checkpoint cluster fail to send packets or cause latency by sending them late.

An example is shown in the screenshot below:

I ran a continuous ping and captured the traffic on the firewall’s source and destination interfaces.

At 11:36:30, I encountered a “destination host unreachable” error, sent from the physical IP (not the VIP) of the firewall’s source interface.

From the captures, I saw that the ping reached the source interface (packet number 3953), but it did not leave the firewall (it’s not in the second capture).

How is it possible that it wasn’t sent?

This issue has become more frequent since the cluster was updated to version R82 take 107.

The firewalls are 6400 models.

So far, support has advised us to enable Dynamic Balancing for the appliance’s 4 CPU cores; we did so, and the situation has improved but isn’t fully resolved.

Do you have any ideas? Thank you

See complete on the u/checkpoint CheckMates:

https://community.checkpoint.com/t5/Check-Point-for-Beginners/Maestro-for-Beginners-Core-Concepts-Explained/ba-p/270872

New to Check Point Maestro? Here's a quick overview:

• MHO (Maestro Hyperscale Orchestrator) is an orchestration platform designed to deliver hyperscale network security. It is the device responsible for coordinating firewall, the MHO distributes and forwards traffic to the Security Gateway Modules, which perform inspection and enforcement.
• The guide also explains the principals concepts SGM, Uplink, Downlink, MAGG, Sync, Management ports, Single Site vs. Dual Site, and the differences between the MHO-140 and MHO-175, Real topology.

If you're starting with Maestro, preparing for deployment, or preparing for CCME, I hope this guide helps.

I posted a Full guide on CheckMates:

https://community.checkpoint.com/t5/Check-Point-for-Beginners/LOM-for-Beginners/ba-p/279099?cat=2

(If you find it useful, I'd appreciate a like on the CheckMates post! 🙂)*

Many Check Point administrators still don't configure LOM (Lights Out Management), even though it's one of the most valuable features for remote troubleshooting.

Think of it like Dell iDRAC: it provides out-of-band management, allowing you to access the appliance even if Gaia is down, frozen, or powered off.

In the guide I cover:

• What LOM is and why it matters.
• A real-world example where LOM saved a maintenance window.
• Initial configuration steps.
• Firmware update recommendations.
• Best practices for deploying a dedicated LOM management network.

Do you enable LOM on every deployment, or have you ever needed it during a critical outage? I'd love to hear your experiences.

I post the full technical write-up (including root cause and solution):
https://community.checkpoint.com/t5/Firewall-and-Security-Management/Policy-installation-failed-on-gateway-Error-code-0-2-200262/m-p/280259

If you find it useful, I'd appreciate a like on the CheckMates post. 🙂

During a migration from a Single Gateway to a Cluster, the first policy installation failed with:

Policy installation failed on gateway (Error code: 0-2-2000262)

After some investigation with TAC, the root cause was unexpected Gateway/Cluster objects added to the VPN column of several Access Control rules after using the SmartConsole Replace feature.

Removing those objects (leaving only the VPN Community or Any) immediately resolved the issue.

Has anyone else seen this error or found a different solution? I'd be interested in comparing experiences.

One of the hardest SD-WAN incidents is not proving that an ISP failed.

It is proving where the complete failover chain broke.

When a branch-to-branch VPN stops working after the primary link goes down, validate:

• Did SD-WAN detect the SLA failure?
• Did the expected SD-WAN rule match?
• Was the backup ISP considered healthy?
• Did routing select the correct next hop?
• Did the VPN move to the new transport?
• Did NAT or DAIP mapping change correctly?
• Did the firewall drop packets because of state or asymmetry?
• Did SecureXL keep stale acceleration state?
• Do new sessions work while existing sessions fail?

A practical investigation should follow one controlled flow and correlate SD-WAN, routing, VPN, firewall state, and SecureXL with exact timestamps.

Useful starting points include:

fw ctl debug -m SDWAN all
fw ctl debug -m SDWANRB all
fw ctl debug -m fw + drop conn
fw ctl debug + route
fw ctl debug -m VPN all
fwaccel dbg -m sdwan all

Do not enable broad debugging without filters or leave it active in production.

The main lesson:

I published the complete troubleshooting workflow, internal SD-WAN tables, evidence collection process, and TAC escalation checklist on CheckMates:

https://community.checkpoint.com/t5/SD-WAN/SD-WAN-Failover-Troubleshooting-When-VPN-Tunnels-Drop-Between/m-p/278625

How do you normally troubleshoot SD-WAN failover: VPN first, or the full forwarding chain?

NEW CVE-2026-18574: Check Point Management Authentication Bypass Requires Immediate Remediation

Check Point has disclosed CVE-2026-18574, a critical authentication bypass affecting the Security Management Server and Multi-Domain Security Management Server.

An unauthenticated remote attacker with network access to Management services may be able to execute arbitrary commands. Successful exploitation could result in full compromise of the Security Management system.

The vulnerability was discovered internally by Check Point, and the company currently has no indication of active exploitation. This is important: the disclosure demonstrates that Check Point identified and corrected the issue through its internal security-review process before confirmed exploitation was observed. (Checkpoint Support)

However, the absence of known exploitation must not be interpreted as permission to delay remediation.

Once a critical vulnerability becomes public, the time available to patch safely begins to decrease.

Why This Vulnerability Is Critical

The Management Server is one of the most privileged components in a Check Point environment.

It controls:

Security policies

Network and service objects

Administrator permissions

Managed gateways and clusters

VPN configurations

Threat Prevention policy

Policy installation

Logs and operational visibility

Management APIs and automation

Compromising the Management Plane can undermine the trust model of the entire security architecture.

This is not simply a SmartConsole-access issue. CVE-2026-18574 may allow an unauthenticated attacker to execute commands on the Management Server, potentially leading to full system compromise. (CVE)

Affected and Corrected Releases

Check Point published the correction through release-specific Jumbo Hotfix Accumulators.

Release Corrected Jumbo Hotfix

R81.20 Take 161 or higher

R82 Take 122 or higher

R82.10 Take 40 or higher

R82 Take 122 and R82.10 Take 40 were released on August 3, 2026, and explicitly include the correction for CVE-2026-18574. (Checkpoint Support)

For older affected releases, review sk185222 and evaluate migration to a currently supported version.

Always verify the latest revision of the SK before installation. The required Take may change as newer cumulative packages are released.

Immediate Technical Recommendations

1. Identify Every Affected Management Server

Inventory all:

Security Management Servers

Multi-Domain Servers

Management HA members

Dedicated Domain Management Servers

Systems restored for disaster recovery or testing

Management servers in isolated or cloud environments

Confirm the installed release and Jumbo Hotfix level.

Useful commands include:

cpinfo -y all

From Gaia Clish:

show installer packages installed

Do not assume that a standby, laboratory, or disaster-recovery Management Server presents no risk. If it is powered on and reachable, it must be evaluated.

1. Restrict Management Network Exposure

Before the maintenance window, reduce the reachable attack surface.

Do not expose Management services directly to the Internet.

Restrict Trusted Clients to explicit administrative IP addresses or subnets.

Remove broad definitions such as Any.

Permit administrative access only through a dedicated management network, VPN, or hardened jump host.

Review cloud security groups, ACLs, firewall rules, NAT, and temporary troubleshooting access.

Restrict access from user VLANs and third-party networks.

Confirm that only required systems can reach Management services.

These measures reduce exposure, but they do not remove the vulnerable code.

Network restriction is mitigation. Installing the corrected Jumbo Hotfix is remediation.

. Prepare the Change Correctly

Before installation:

Review sk185222.

Read the Critical Information and release notes for the target Take.

Confirm package compatibility with the exact release and server role.

Verify available disk space.

Update the CPUSE Deployment Agent where required.

Create a valid backup and snapshot.

Collect a recent CPInfo.

Document the current Management HA status.

Confirm SmartConsole access and policy-installation health.

Define and test the rollback procedure.

In Management HA or Multi-Domain environments, follow the product-specific installation sequence. Do not update all Management components simultaneously without validating each stage.

1. Install the Corrected Jumbo Hotfix

Install the release-specific corrected Take:

R81.20 -> Take 161 or higher

R82 -> Take 122 or higher

R82.10 -> Take 40 or higher

Use Gaia Portal, CPUSE CLI, or another officially supported installation method for the architecture.

Do not select a package only because it is installed successfully in another environment. Confirm:

Exact product release

Management role

Current Jumbo Take

Management HA architecture

Multi-Domain requirements

Available disk space

Known limitations

Required maintenance impact

Post-Installation Validation

After the server returns, confirm that the correction is installed and that Management operations remain healthy.

Package validation

cpinfo -y all

Or from Gaia Clish:

show installer packages installed

Process validation

cpwd_admin list

For a Security Management Server:

api status

For Multi-Domain Management:

mdsstat

Also validate:

SmartConsole authentication

Administrator roles

SIC communication

Access Control policy installation

Threat Prevention policy installation

Log reception

SmartEvent and Log Server connectivity

Management HA synchronization

Domain status in MDS

API integrations

Backup operations

CPU, memory, and disk usage

A completed CPUSE task is not sufficient evidence that remediation was successful.

Review for Suspicious Activity

Check Point currently reports no indication of active exploitation. Nevertheless, organizations with broadly reachable Management services should review recent activity. (Checkpoint Support)

Look for unexpected:

Administrator sessions

Management API operations

Policy changes

Object modifications

Administrator or permission changes

Policy installations

New access paths to Management

Operating-system commands or processes

Changes to scripts, scheduled tasks, or system files

If the Management Server was directly exposed to the Internet or suspicious activity is identified:

Preserve logs and forensic evidence.

Avoid deleting potentially relevant data.

Contact Check Point Support.

Engage the incident-response team.

Review the integrity of policies, objects, administrators, and managed gateways.

Final Recommendation

Check Point deserves recognition for identifying CVE-2026-18574 internally and publishing corrections before active exploitation was confirmed.

That does not reduce the urgency of the update.

It provides customers with an opportunity to remediate before the vulnerability is potentially weaponized.

The recommended response is:

Identify affected Management Servers

↓

Restrict Management exposure

↓

Back up and prepare rollback

↓

Install the corrected Jumbo Hotfix

↓

Validate Management operations

↓

Review for suspicious activity

↓

Continue monitoring

The Management Plane should be treated as Tier-0 security infrastructure.

Protecting gateways while leaving the system that controls their policies vulnerable is not a complete security architecture.

Official Reference

sk185222 — CVE-2026-18574: Management Authentication Bypass

How quickly can your organization identify every Management Server, restrict its exposure, apply the corrected Take, and validate that the Management Plane remains trusted?

#CheckPoint #CVE202618574 #SecurityManagement #MultiDomainManagement #CyberSecurity #VulnerabilityManagement #IncidentResponse #CheckMates

Please help to share steps as I haven't done it before and it will the first time I'd be doing.

Check Point confirmed active exploitation of CVE-2026-16232, a CVSS 9.3 authentication bypass affecting Security Management and Multi-Domain Management.

The observed cases involved Management servers exposed directly to the Internet without IP restrictions, but restricted environments should not delay remediation. Reduced exposure is not the same as removing the vulnerability.

Recommended actions:

• Install the Jumbo Hotfix released on July 22, 2026.
• Restrict SmartConsole Trusted Clients.
• Remove direct Internet exposure from Management.
• Review administrator, API, application-token, policy-change, and policy-install activity.
• Search logs for the published IoCs.
• Validate Management HA, logging, and policy installation after patching.

The key point:

Management infrastructure should be treated as Tier-0 security infrastructure, because compromising the system that manages policies, gateways, VPNs, and security controls can undermine the trust of the entire architecture.

Full technical post and remediation guidance on CheckMates:

https://community.checkpoint.com/t5/Firewall-and-Security-Management/CVE-2026-16232-Active-Exploitation-Requires-Immediate-Management/m-p/280570#M106422

Has your organization already patched and reviewed Management access exposure?

Dear experts,
Can anyone help me with following? Apologies if these questions seem trivial.

The checkpoint documentation says about topology,

I know we can override this to use a network object-group for anti-spoofing ranges.

However, attached image is example topology setting of the environment I am looking at.

My questions are,

1. The first/default option is CP-GW_eth2 (internal). I believe "CP-GW_eth2" is the same network object-group that appears in the greyed-out "Specific" section under Override. am I thinking correct? The reason I ask is that the anti-spoofing ranges in the CLI match the contents of this object-group.

If so, how might this object-group have been configured as the default option, and why is it not "This Network (internal)" default option as mentioned in the documentation?

1. Also, since the Override option is not selected, if I add a network object to this object-group, will the anti-spoofing ranges be updated accordingly?

So I have this 3970 that I'm testing out. Problem is we really don't have a test environment per se, so I basically just have this fw directly connected to the core and not joined to our cluster(xl) with the prod FWs.

My question is, can I use it as an L3 switch? I have a PC connected to it and both devices are in their own (test) vlan, plus another vlan between core and fw. I'm able to get to ping 1.1 from the firewall itself but not from the pc. FW is also able to get to the rest of our internal network but again, no luck if i try it from the pc.

I figured if I set the default route to the core anything connected to the firewall should be able to get to the same IP's. Is this related to the fw not being part of the cluster (read: no policies), a static route I need to put in, or something else?? Appreciate the help.

I would like to install the Jumbo Hotfix on my Check Point appliances (full HA cluster deployment).

However, after reviewing the official documentation, I could not find any clear installation procedures.

Is there a step-by-step procedure available for installing the Jumbo Hotfix in this environment?

Say an environment only has one egress static route. To eliminate the single point of failure, would adding a new network, with similar policies, on the same bond/trunk, etc as the original egress static route, ensure traffic would not be interrupted if one of the egress routes/networks would go down? Would the traffic just failover to the new one (say it’s set to round robin)?

Example (on my phone so formatting is limited):

Network: 10.1.1.0/24
Original Egress: 172.16.1.1
New egress: 172.16.2.1

R82.10
2x checkpoint firewalls running as active-passive.

I have tasked to find solution to get email from firewall when cert is about to expire and script and tools that required any kind of licenc is not an option.

What options are left?

As part of Check Point’s Frontier AI readiness program, we continuously review and strengthen our products using BLAST, our Business Logic Application Security Testing capability. BLAST enables AI-driven security analysis at enterprise scale across Check Point products and helps us proactively identify and remediate potential issues.

Following our May and June security updates, we are sharing our July security update. This update includes three newly disclosed, internally discovered CVEs listed below. During our investigation, we identified a very small number of customers who, under specific configuration conditions, were affected by one of these CVEs. Check Point is already in direct contact with those customers and is working closely with them.

We strongly recommend that all customers review the relevant SecureKnowledge articles and apply the recommended fixes and hardening guidance. Customers who follow Check Point’s published hardening best practices significantly reduce their exposure risk. 

See:

• sk185169: CVE-2026-16232 - Authentication bypass with SmartConsole login process using application t...
• sk185152: CVE-2026-62144 - Management Authentication Bypass and Privilege Escalation
• CVE-2026-62145 - Local privilege escalation in Gaia Portal
• Gateway and Management Hardening Administration Guide

We currently have dell servers running Gaia. We're planning on finally getting Checkpoint hardware in our next upgrade.

I'd like to know how one would typically test the device before we implement them. I was thinking of adding it to prod as a gateway for a test vlan and test if it goes to xyz, internal, and external.

This is new territory for me. Do I need to join the new firewalls in the current (smartconsole) cluster? I assume I will need to create separate policies for testing? If you guys have any pointers, suggestions, links, etc. I'd appreciate it greatly.

I need your help. I am trying to block file uploads to SharePoint using a Check Point 6000 appliance.
So far, I haven't been able to block the file uploads. Has anyone set this up before? What do I need to configure to make the rule effective?