Check Point fixes CVE 2026 93616 path traversal in Management Server after 23 Jul attacks

On July 23, targeted attacks were detected that took advantage of a vulnerability until then unknown in the web service of the Security Management Server of Check Point, according to the company. The failure, recorded as CVE-2026-93616, allows an attacker to reach the server's web service to upload and run scripts without authentication. Check Point published a correction on September 22 and has published mitigation and commitment-seeking guidelines on its technical support.

Confirmed facts: Check Point has recognized the existence of a path-path vulnerability in the web service of the management server which, in affected versions, does not correctly limit files and folders accessible by remote requests. That failure can be used to place scripts on the server and run them. The company assigned a CVSS score of 9.8, published a hotfix and published guides on its support portal ( support.checkpoint.com). In addition, Check Point confirmed attempts to exploit from 12 September against another VPN vulnerability (CVE-2026-85102) that had been parked on 9 September; these attempts targeted Spark and gateways devices that had not received the correction.

What remains uncertain and requires additional confirmation: Check Point has not publicly identified the specific objectives of the July 23 attacks, who were the attackers and what concrete actions they took after exploiting CVE-2026-93616. Nor has it stated whether attempts against VPN vulnerability (CVE-2026-85102) succeeded in any environment. The company has indicated that the attempts came from anonimization infrastructure (VPN and proxies) and that certificates have been observed with certain subjects, but the list of certificates seen is not necessarily exhaustive.

Technically, the new vulnerability is a path traversal in the Management Server web component: when the service does not properly restrict the requested file routes, a manipulated request can access locations outside the planned tree, upload malicious files and then run them. That chain - access to the web service without authentication, script uploading and execution - turns vulnerability into a remote code execution vector with a potentially critical impact on the confidentiality and integrity of firewall policy management.

Who's it to? The affected versions and buildings are listed by Check Point with granularity by "R" release and by Jumbo Hotfix number "Take." In practical terms, the risk lies with managers who manage Security Management Servers - central who control policies and distribute settings to gateways - and with Spark and gateways customers who, if not in the parched building, can also be the subject of prior or parallel operating attempts. Since the management server controls safety rules and objects, its commitment can allow an attacker to modify rules, create exit routes, hide traffic or deploy persistence in the network infrastructure.

Real consequences and risk scenarios: a committed management server can facilitate side movements and persistence in the corporate network, alteration of firewall policies (e.g., opening of ports or creating rules allowing unauthorized traffic), interception or redirection of traffic, and deployment of backdoors in managed gateways. In addition, the difficulty in detecting previous activity makes the simple installation of the patch not evidence that there was no intrusion.

Specific and immediate measures to be taken by security managers and officials- verifiable and prioritized actions:

1) Check the version and the Jumbo Hotfix take from the Security Management Server and compare it to the list of affected buildings provided by Check Point. If you do not have the information, see the management interface and the documentation of your release. Install the hotfix or LivePatch indicated in the corresponding support article (reference in the Check Point portal).

2) Follow the Hunting guides and commitment indicators that Check Point published in its support article (see your support portal for sk1000171). This includes reviewing web service logs, looking for files and scripts recently uploaded in web directories, reviewing cron jobs or programmed tasks, and checking abnormal network processes and connections.

3) Assume the possibility of engagement if the server was in a vulnerable version between the July 23 window and the patch publication. In such cases, activate incident response measures: putting management server in maintenance mode or isolating it from the network, collecting and preserving log and evidence (before applying patches that can overwrite artifacts), and, if necessary, using professional forensic analysis to confirm the scope and presence of back doors.

4) Review the integrity of the configuration and policy rules: compare back-up of previous configurations with the current state, inspect recent changes to rules that are not justified and validate that there are no duplicate or modified accounts, objects or policies without authorization.

5) For VPN vulnerability (CVE-2026-85102): confirm that the Gateways and Spark devices have applied the patch published on September 9 (relevant support article and mitigation in sk1000117). Review Mobile Access and certificates used for early session; Check Point observed attempts with certificates using CN = vpn, CN = vpn-user or CN = vpnuser type subjects, but the list may not be complete. Look for early session with out-of-the-box certificates and any subsequent activity like internal scans.

6) If you cannot apply patches immediately, implement the workarounds advised by authorities such as the Dutch NCSC: for example, for Site-to-Site VPNs limit the incoming traffic of UDP 500 / 4500 only to PIs of known pairs and disable implicit rules of VPN where appropriate. See the NCSC guide for operational instructions and apply temporary network access controls ( www.ncsc.nl).

7) Rotate sensitive, certified and key credentials that Management Server may have used, once the instance has been cleaned or rebuilt, and review access to management accounts to detect unauthorized creations or privilege elevations.

Medium-term recommendations and good practices: keep the patch cycle up to date with LivePatch / Takes attention (the differences between Jumbo Hotfix and LivePatch can leave some partially protected buildings), segregate the production network management console, apply access controls (source control lists) for access to management web service, and enable monitoring of integrity and early warnings on critical policy changes.

Additional resources and references: See the Check Point support portal for official notes and corrected build-ups, and response guides published by national cyber security teams such as the Dutch NCSC and sectoral response teams (for example, CERT Santé in France has published summaries that amplify the check point communication). Useful links: Check Point Support ( https: / / support.checkpoint.com) and the Netherlands ( https: / / www.ncsc.nl), in addition to the site of the French Health CERT ( https: / / www.cert.sante.gouv.fr).

Final distinction: patches and mitigations are indispensable but not sufficient to declare a "clean" environment. Since Check Point has not made public the evidence of the extent of the July attacks, the responsible action to vulnerable servers is to treat them as potentially committed until a detection process and, if appropriate, a forensic, proves otherwise.