Two Check Point vulnerabilities added to CISA’s Known Exploited Vulnerabilities catalog on September 22 require different fixes and different verification steps. CVE-2026-85102 affects certificate validation in multiple products and has been observed in attacks against Spark firewalls. CVE-2026-93616 is a path-traversal and file-upload issue affecting Security Management Server releases and can allow unauthenticated script upload and execution.
The practical mistake would be to treat “LivePatch installed” as a universal answer. Check Point explicitly states that LivePatch Takes 28 and 29 do not remediate CVE-2026-93616. Teams need a product-by-product matrix that records version, hotfix level, applicable patch, exposure, and evidence review.
Build the remediation matrix
Create one row for each gateway, Spark appliance, management server, log server, and standby node. Capture the product family, exact release, Jumbo Hotfix take, installed LivePatch take, internet reachability, management role, and patch owner. Verify values on the system instead of copying an aging inventory.
For CVE-2026-85102, follow Check Point sk1000117. The vendor says active exploitation against Spark firewalls was observed as of September 12 and identifies scenarios that require LivePatch Take 26. Validate applicability against the exact release and Jumbo Hotfix level.
For CVE-2026-93616, use Check Point sk1000171. The affected set includes R82.20; R82.10 with Jumbo Hotfix Take 44 or earlier; R82 with Take 126 or earlier; R81.20 with Take 166 or earlier; and R81.10 with Take 190 or earlier. Older R80 and R81 families are end of support and should be treated as migration work, not patched exceptions.
Separate patch presence from patch effectiveness
Check Point LivePatch can validate and apply protections and may reapply them after process restarts or reboot. That operational behavior is useful, but the console state must be checked after maintenance. Record the patch identifier, application time, validation result, and current status for every node.
For the management-server flaw, do not count Take 28 or 29 as remediation. Apply the vendor-prescribed software update or hotfix for the affected branch, then verify the effective build. Patch standby management servers and disaster-recovery systems as well as the active node.
Reduce exposure during the change window
Restrict management interfaces to dedicated administrative networks and bastions. Remove direct internet exposure, review published NAT rules, and verify cloud security groups. For Spark appliances, limit administration to trusted sources and disable unused remote-management services.
If patching must wait, isolate vulnerable systems behind an upstream control with explicit allowlists. Temporary filtering is not a substitute for remediation, particularly for a vulnerability that supports unauthenticated code execution.
Investigate both the gateway and management tiers
Preserve logs before cleanup. Review authentication events, administrative sessions, policy installation, object changes, file creation, script execution, and processes launched by web or management services. On management servers, search for unexpected files in web-accessible and temporary paths and correlate their timestamps with inbound requests.
Use network telemetry to identify unusual outbound connections from systems that normally initiate little external traffic. Compare configuration and filesystem state with a known-good peer. If unauthorized execution is suspected, rotate administrative credentials, API keys, certificates, and secrets available to the affected server, then rebuild from trusted media when integrity cannot be established.
Account for management dependencies
Security Management Servers commonly integrate with identity providers, ticketing systems, automation accounts, log collectors, and backup repositories. Add those trust relationships to the incident scope. An attacker who reached the management tier may have obtained credentials that remain valid after the server itself is patched.
Review recent policy packages and installation history for subtle changes, including permissive rules, modified objects, altered logging, and new administrative access paths. Export the effective policy for comparison with the approved baseline. Where multi-domain management is used, perform the review per domain rather than relying on a global summary.
For clusters, validate that every member received the appropriate fix and that failover does not return traffic to a vulnerable node. For centrally managed Spark appliances, confirm both the local device status and what the management console reports; resolve mismatches instead of accepting the more favorable view.
Prove closure
CISA’s September 22 notice confirms both vulnerabilities are associated with real exploitation. Close the work only when the matrix has no unowned systems, every applicable node has the correct fix, management exposure is constrained, and the investigation result is documented. That evidence prevents a green patch dashboard from hiding a vulnerable management server or an unpatched standby appliance.
