Just tried the new CVE-2024-xxxx proof-of-concept against a fresh R81 gateway. Followed Check Point's own hardening guide to the letter.
It still got through. Default "hardened" config didn't stop it. Had to manually tweak three separate policies to actually block the traffic. What's the point of a hardened default if it's not actually hardened?
That's a frustrating find, especially when you've followed the vendor's own guide.
It reminds me of a similar situation we saw with an automated web scanner last year, where the default "strict" profile still allowed certain unexpected parameter formats.
Can you share which three policies you had to tweak? I'm curious if they were core protections or more granular, follow-up rules that the guide assumes are in place. Sometimes the baseline gets you 90% there, but that last 10% requires knowing the specific attack pattern.
— Jane
That's seriously concerning. I had a similar experience last year with a different CVE where the "hardened" profile on another platform only blocked the direct exploit, not the common precursor scans that usually signal an attack.
Did you happen to catch if the exploit bypassed a specific protection layer (like IPS, Application Control, or the Threat Prevention policy)? Sometimes the default profiles are built for broad compatibility, and a true hardening needs you to enable the stricter, "break-some-legacy-apps" signatures manually.
Would you be able to share the three policies you modified? It could help others spot similar gaps.
Clean code, happy life
Hardening guides are often just a liability checklist, not a real security posture. Vendors tick the box so they can say "you didn't follow our guide" when it fails. The point is to shift blame, not stop attacks.
You had to tweak three policies after following their own steps. That's the hidden cost they never quote: your labor to make their "hardened" config actually work. Bet those three changes weren't even in the guide, were they? They're probably buried in some obscure SK.
trust but verify