topic Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes in General Topics

Concerns About the Reliability of Recommended Jumbo Hotfix Takes

israelfds95 — Mon, 14 Sep 2026 21:32:29 GMT

Hi CheckMates community and Check Point team,

I would like to raise a concern regarding the current situation with Recommended Jumbo Hotfix Takes.

Recently, I have received questions and concerns from customers about the lack of a current Recommended Take. At the same time, there is growing concern about the reliability of Takes that receive the Recommended status, as we have seen multiple cases where Recommended JH Takes introduced significant issues in production environments.

We always follow best practices and perform our own validation before permanently deploying a new JH Take in production. However, the Recommended status from Check Point is an important part of our decision-making process. Customers and partners need to have confidence that a Take marked as Recommended has reached an appropriate level of maturity, testing, and validation for production use.

For R82, we recently tested the latest Take 126 because of the need to address recent CVEs. Unfortunately, during our validation, it did not behave as expected, so we decided not to move forward with it in production.

We are now waiting for the next Recommended Take, but this situation is also generating questions from customers: when a Take is marked as Recommended, how confident can we be that it has undergone additional validation and is considered solid for production environments?

The frequency of issues we have encountered with some Recommended Takes is beginning to affect customer confidence in the Recommended status itself. This is particularly concerning in critical environments, where upgrading a JH can have a significant operational impact.

I would appreciate some clarification from Check Point regarding the criteria and validation process used before a Take receives the Recommended status, and whether there are plans to strengthen this process.

Ultimately, what we need as partners and customers is not simply a new "Recommended" Take, but a Recommended Take that we can confidently use as the baseline for production deployments.

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

PhoneBoy — Mon, 14 Sep 2026 22:24:14 GMT

From Check Point Recommended Version and Release Terminology which has recently changed:

Each Jumbo Hotfix Accumulator is considered Recommended from the day of its release, as it contains important security, hardening, stability, and product fixes.
Customers should plan to adopt each latest Jumbo Hotfix Accumulator as part of their regular maintenance and security update process, following their standard testing and change management procedures.
We also provide adoption-level information for each released Jumbo Hotfix Accumulator (widely and early) and provide renumbers under each section, offering greater transparency and helping customers make informed deployment decisions.
For more information about Jumbo and its Terminology, see sk98028.

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

Bob_Zimmerman — Mon, 14 Sep 2026 22:36:40 GMT

This is particularly relevant when you look at the fix cadence in past jumbos. We'll typically get one with ~150 fixes, then a second a few weeks later with 2-3, and the second is the one which goes recommended. R82 jumbo 25: 206 fixes. R82 jumbo 33: 3. R82 jumbo 34: 2. Guess which ones went recommended.

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

Bob_Zimmerman — Mon, 14 Sep 2026 22:50:22 GMT

"We also provide adoption-level information" is incorrect, as the information isn't provided yet, even days after this change was announced. To be able to use it, we will need data going back a year or two so we can see when things went recommended in the past.

All of our internal processes are worded such that we're not allowed to install a jumbo when it's newly released, only when it is moved to a separate recommended state. They were built this way after somebody deployed a jumbo too early and hit a new bug. Recommended from day 1 doesn't fit this, so now on top of multiple hair-on-fire emails telling us to install a security fix everywhere, then multiple more hair-on-fire emails telling us to install a new version of the fix everywhere, you've made a mountain of internal process work with zero reference we can use to build new processes.

There should really have been a transition period for this change.

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

israelfds95 — Mon, 14 Sep 2026 23:03:29 GMT

Thanks for the clarification. After reviewing sk98028, I think this actually reinforces my concern.

If every Jumbo Hotfix Accumulator is considered Recommended from day one, what additional level of validation, maturity, or production readiness does the “Recommended” status actually represent?

I completely agree that customers must perform their own testing and change management, we always do. However, deploying a JHA to a critical environment may require significant planning, maintenance windows, backups, reboots and rollback procedures. If a Take officially marked as Recommended introduces serious issues affecting the Check Point solution itself, the operational impact can be significant even with proper change management.

From a customer perspective, when the vendor officially marks a release as Recommended, there is a reasonable expectation that the vendor considers it sufficiently validated and reliable for production, with customer testing providing an additional layer of assurance.

If every new Take is automatically Recommended regardless of its field maturity, perhaps the terminology should be reconsidered: call it simply Latest, and reserve Recommended for a Take that has reached an additional level of validation and production maturity.

Otherwise, what practical assurance does “Recommended” provide beyond simply being the latest release?

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

Bob_Zimmerman — Mon, 14 Sep 2026 23:16:48 GMT

That part I kind of understand. If the latest has security fixes, and the recommended is an earlier one, are they recommending we skip security fixes? That would be really bad optics for a security company. They obviously have to recommend we install security fixes, but those aren't separated from bugfixes and feature updates; it's all just one jumbo.

Raw adoption data (ideally with data about new bugs seen in a jumbo) is definitely better than an opaque recommended/not flag. But we really need the data before the old pattern is no longer available.

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

JozkoMrkvicka — Tue, 15 Sep 2026 06:46:04 GMT

Check Point will use CPLP (LivePatch) to fix security fixes/CVEs (without reboot/cpstop). These security packages will be independent from Jumbo Take. Until next "Latest" Jumbo is released (minimum once per month), you will be already protected by CPLP package.

If there will be some critical bug in Jumbo which you are supposed to install (since it is already recommended from day 1 of release), new Jumbo will be released with only 1 bugfix. It will end up having too many maintenance windows in very short period of time. Too many work for every administrator (doing rollback or updating to latest Jumbo + long processes and approvals by corporates). Not saying that there are many freeze periods where changes are not allowed. If someone prepares change to install Take X in 3 weeks from now, it might happen that once the change is approved and released for implementation, next Take Y will be released (already recommended) ...

Or maybe the intention is just to keep our firewalls clean and fresh as every reboot clears cache, memory consumption and temp files ...

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

Hugo_vd_Kooij — Tue, 15 Sep 2026 07:28:58 GMT

Can you share what sort of issues you are having with take 126?

Andhave you eveluated if this could in part be because you deviate from Best Practises? Having said that, finding all the Best Practises is .... painful. So yes, it would be nice if there is a clear set of Best Practises.

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

MeravAlon — Tue, 15 Sep 2026 08:56:54 GMT

Hi @Bob_Zimmerman and all

As @PhoneBoy mentioned, we have updated our terminology.

Regarding adoption visibility, this information is already available and visible to all users. On the download page of each Jumbo SK, you can see the current adoption status, such as Initial Adoption or Wide Adoption.

For reference, all of the latest Jumbo releases were promoted to Wide Adoption yesterday.

Thanks.

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

israelfds95 — Tue, 15 Sep 2026 12:50:50 GMT

Thanks, I understand the new terminology and the adoption visibility now.
However, my main concern is still different. We are seeing JH causing significant issues with Check Point products in production, and this is becoming a recurring concern for customers.
Customers are starting to question the level of testing and validation performed before these Takes are released. Regardless of whether the terminology is Recommended, Latest, Initial Adoption or Wide Adoption, what we really need is confidence that a released JH has been thoroughly tested by Check Point across Check Point products and their core functionalities before customers are asked to deploy it.
My intention with this post is mainly to bring visibility to this issue. The recent experience with problematic JH is creating operational impact and reducing customer confidence. I hope Check Point can take a closer look at the validation and release process, because ultimately, terminology is secondary. What customers and partners need most is reliable JH.

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

israelfds95 — Tue, 15 Sep 2026 13:16:20 GMT

Regarding R82 JH Take 126, initially everything appeared to be working normally after installation. This was already an improvement compared to Take 122, where we had an issue with Mobile Access rule processing, which was later addressed by Check Point with a specific portfix.

However, after running Take 126 for some time, the gateway started repeatedly displaying the following message over SSH:

Kernel: watchdog: BUG: soft lockup - CPU23 stuck for 22s

After that, we also started experiencing VPN instability. Based on this behavior, I decided not to move Take 126 into full production for this customer and kept them on JH Take 91, which has been stable in their environment.

Another important issue occurred during the rollback. After reverting Take 126 on the Security Management Server, the SMS did not recover properly. CPM and API processes entered a loop, attempting to start and returning to Stopped state. Fortunately, I had taken a VM snapshot before the change, so I was able to restore the SMS quickly.

Because of experiences like these, my current approach before deploying a new JH is:

Always schedule a maintenance window.
Back up as much as possible before the installation. For virtual Open Servers, whenever possible I take a VM snapshot, System Backup and migrate export. For gateways, I keep a System Backup and show configuration, and any relevant file like fwkern.conf,trac.client,ipassignment,fastaccel ....
For ClusterXL HA, I upgrade only the Standby member first. I then promote it to Active and validate the customer's services and normal production traffic with the new JHA while keeping the other member on the known stable Take.
I keep this validation running during 1 day or 1 week before upgrading the second member. If abnormal behavior appears, I can fail back to the member running the previously stable Take.
For virtual Security Management Servers, I consider the VM snapshot especially important. If the upgrade or revert leaves management processes unable to start, restoring the snapshot can be significantly faster than rebuilding the SMS and restoring from backup/export.
For Maestro, I start with a small number of Security Group Members, following the recommended procedure, validate the behavior, and only then proceed with the remaining members.

This approach obviously requires more planning, but after the issues we have experienced with recent JH, I prefer to treat every new Take as something that must prove stable under the customer's real production traffic before completing the rollout.

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

ccsjnw — Tue, 15 Sep 2026 18:51:42 GMT

I completely understand your concern, but unfortunately the rapidly accelerating risks due to advanced AI finding vulnerabilities in security platforms in a *very* short period of time, means the slower, more cautious patching and testing pattern that we previously used, is no longer adequate to provide the protections we need today.

If we look back a few years, it was much the same with Microsoft patches: a slow adoption after careful testing, but nobody can afford the time to do this anymore - and yes, sometimes things break after the monthly cumulative update, but the world has changed - and end users (and managers), now accept the monthly patching ritual and organisations have mandated policies and procedures which reflect this pratice.

I personally welcome CheckPoint’s move to provide frequent ‘Recommended’ updates - previously, it could be *months* before a ‘Recommended’ update became available, and many of us work in environments where policies prevent us installing updates before they reach ‘Recommended’ status even when they are considered critical - the idea of having a patch that is critical, but not recommended is nonsensical in my opinion - it sends out the wrong message to the community, so I’m very pleased this is changing.

For many of us, predictability and the ability to quickly uninstall a patch if it does cause a problem is of the highest priority.

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

israelfds95 — Tue, 15 Sep 2026 16:22:43 GMT

I agree with you. The current security landscape, especially with AI accelerating vulnerability discovery, definitely requires a much faster response.
In fact, I think Check Point Live Patch (CPLP) is a fantastic step in this direction. Being able to address critical CVEs independently of the normal Jumbo Hotfix cycle is a major improvement.
My concern is that faster patching should not come at the cost of JH quality. There is little benefit in releasing a security update quickly if the JH introduces another serious issue in the product and, as a result, we cannot keep it in production.

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

Lari_Luoma — Wed, 16 Sep 2026 04:32:32 GMT

💯

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

Stephen_Vella — Wed, 23 Sep 2026 08:48:55 GMT

Agree with @israelfds95. Our customesr are facing same issues 😞 applying fast JHFs and sometimes even with some custom hotfix wrapper is becoming a nightmare with a lot of customer issues after, services crashing, cluster failing over with fwk dumps etc . Security is of concern, but stability cannot be put aside.

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

israelfds95 — Sat, 26 Sep 2026 03:03:24 GMT

This is exactly what I have been talking about.

I had issues with R82 JH Take 122. I had issues with R82 JH Take 126. And now, after installing the recently released R82 JH Take 127, I am experiencing issues again.

In all three cases, I had to uninstall the Jumbo Hotfix because of problems identified on the cluster during our maintenance and testing window. This environment belongs to an extremely important customer here in Brazil.

This is precisely my point: there is little benefit in releasing Jumbo Hotfixes quickly if it appears that they are not being tested thoroughly enough before release.

In our case, keeping critical customer environments compliant requires a significant operational effort. Obtaining a maintenance window can take weeks or even months of planning, including management approval and coordination across multiple teams. Having to roll back the update at the end of that process creates significant operational challenges, especially when management is also demanding compliance, CVE remediation, and an up-to-date environment.

For this reason, I strongly believe Jumbo Hotfixes need more extensive testing, and that Check Point needs to ensure the quality and stability of these packages, not only for customers but also for the engineers and teams responsible for maintaining these environments.

With JH Take 127, I am now seeing a serious issue during policy installation. At approximately 75% of the Install Policy process, the firewall starts experiencing severe packet loss affecting Internet-bound traffic, VPN traffic, and internal traffic. Once the policy installation finishes, traffic returns to normal. This behavior was not occurring before installing Take 127.

For now, I am remaining on JH Take 91.

At least I have enabled Check Point Live Patch (CPLP), which helps reduce some of the exposure. However, the latest CVE is not covered by CPLP. I have implemented all applicable mitigation measures to reduce the exposure to these CVEs and keep my customers' environments as protected as possible while maintaining the stability of their production systems.

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

JozkoMrkvicka — Sat, 26 Sep 2026 12:15:19 GMT

Did you face issue with installing policy when Take was installed on management or gateway ?

The latest CVEs (CVE-2026-91843 + CVE-2026-93616) are relevant only for management.

You can also try to request from Check Point portix just to fix CVEs on your current Take.

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

israelfds95 — Sat, 26 Sep 2026 12:42:05 GMT

I installed JH 127 on both the SMS and the Security Gateway. However, I kept JH 127 installed only on the SMS and removed it from the Gateway due to this serious issue. After removing JH 127 from the Gateway and rolling back to JH 91, which had been stable in this customer environment, everything returned to normal.

On the production Gateways, I am currently staying on JH 91, with CPLP enabled and the IKEv1 CVE hotfix installed. Given the criticality of this customer environment, I could not keep JH 127 installed on the production Gateways.

I had issues with JH 122, which broke Mobile Access in this environment, and I reported it here. Some time later, Check Point released a hotfix for that issue. JH 126 was also unstable in my testing, and now I am seeing problems with JH 127 as well.

Even though JH 127 includes fixes for CVEs that primarily affect the SMS, it is still a full JH. In this particular case, I think Check Point could have released the relevant fixes as a dedicated hotfix for the SMS instead.

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

JozkoMrkvicka — Sat, 26 Sep 2026 12:56:20 GMT

I fully agree with you.

Instead of including fixes for critical CVEs into new Take, they should have created portfixes for last XY Takes for each version. But they will argue that CPLP is the solution ...

Re: Concerns About the Reliability of Recommended Jumbo Hotfix Takes

israelfds95 — Sat, 26 Sep 2026 13:08:01 GMT

I have been frustrated with the quality of recent JHs, and this is not something new. Since R81.20, I have seen several cases where we install a JH to fix one problem and end up introducing another serious issue, and we need to uninstall.

CPLP has been an excellent solution, and my customers are very happy with the faster response to critical CVEs. However, these recent CVEs that required a JH instead of CPLP have brought this concern back again.

Unfortunately, it gives the impression that JHs are not being tested enough before release, leaving customers responsible for finding issues in production. In the real world, a customer environment cannot be a test lab. The impact of not being able to deploy security fixes is significant, but deploying a JH that causes production issues can be even worse.

In this case, JH 127 was released mainly to address two CVEs. A dedicated hotfix for the affected SMS/MDS systems could potentially have avoided the need to deploy a full JH. I could keep JH 127 on the SMS, but not on the production Gateways due to the issues we experienced, and other engineers on my team are also reporting problems with it.

I continue to believe that Check Point needs to improve JH testing and quality before release, rather than transferring this risk to customers.