Build1 publisher3 min readPublished
Unauthenticated requests to TCP/19009 run scripts on Check Point management servers
CVE-2026-93616 lets a remote attacker upload a file and execute a script on Check Point's management, log and SmartEvent servers with no credentials. Check Point says it observed targeted attacks on July 23, 2026.
The Engineer · Build desk
What happened
- CVE-2026-93616 is a pre-authentication path traversal and file upload flaw in the Check Point Management web service that lets an unauthenticated attacker run a script from an arbitrary path or load an arbitrary Java class.
- Check Point reported observing a small number of targeted attacks on July 23, 2026, and has confirmed exploitation in the wild against a small number of targeted customers.
- Check Point tells operators not to rely on LivePatch Take 28 or 29, because neither LivePatch version addresses CVE-2026-93616.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- contradiction The record carries two severities at once, a CVSS 9.8 and Check Point's own High rating on the alert, so intake tooling keyed to vendor severity will queue this lower than tooling keyed to CVSS.
- decision Sites that adopted LivePatch to keep management servers current have to open a maintenance window and install a hotfix or Jumbo Take for this CVE.
- exposure Code execution on a management server puts management policy and the managed gateways in reach, so one unpatched box extends the blast radius to the firewalls it administers.
The affected list and the fixed list do not meet on two branches. Check Point lists R81.20 as affected through Jumbo Hotfix Take 166, and fixed from Take 170 [7][8]. Takes 167, 168 and 169 sit on neither list [1]. R81.10 is affected through Take 190 and fixed from Take 192, which leaves Take 191 in the same position [2]. R82.10 and R82 are contiguous: 44 affected and 45 fixed, 126 affected and 127 fixed [3]. A server on R81.20 Take 168 therefore has to move to Take 170, or take the hotfix, before the version table clears it [8].
R82.20 is handled differently. The remediation for it is the dedicated R82.20 Security Hotfix, and the fixed Jumbo Takes are listed for R82.10, R82, R81.20 and R81.10 [8][6].
The advisory also tells operators not to rely on Check Point LivePatch Take 28 or 29, because those LivePatch versions do not address CVE-2026-93616 [9]. A site that keeps its management servers current through LivePatch has to install a hotfix or a fixed Jumbo Take for this one [8][9].
Four conditions have to hold for exploitation, according to the writeup: the product is running an affected version or unpatched Take, the attacker can reach TCP/19009, the applicable hotfix is not installed, and the malicious request reaches the vulnerable Management web service and triggers arbitrary-path script execution or Java class loading [12]. Restricting access to TCP/19009 removes one of those four, and it appears on Check Point's mitigation list [13][5].
The vendor's indicators are usernames longer than 1,000 characters in cpm.elg, FWM or MDS core dumps generated at the same time, and ReflectionUtils errors containing suspicious paths such as ../ [14]. Check Point says those indicators show potential exploitation attempts and do not by themselves confirm successful script execution, and that suspicious files, scripts, Java class loading, child processes, management configuration changes and outbound connections are the stronger evidence [15][16]. That evidence lives mostly in server logs, core dumps, file activity and process telemetry [17], including on the Log Server, Multi-Domain Log Server and SmartEvent machines that are themselves on the affected products list [6].
The observed attacks are dated July 23, 2026 [5]. The writeup carries a published date of September 20, 2026 and an update two days later [20]. Fifty-nine days separate the attacks Check Point saw from the record [4]. An investigation opened now is searching July telemetry.
The record scores CVE-2026-93616 at CVSS v3.1 9.8 [2] while noting that Check Point rates its own security alert High [3]. The 9.8 follows from the access model: the attacker is remote and unauthenticated, and no end-user interaction is required [10][11]. The exploit request, the uploaded payload, the persistence mechanism and the post-compromise activity have not been made public, and the activity is unattributed [18]. I would schedule the install on the CVSS score and the confirmed exploitation in the wild [2][4], and treat the vendor's High as a label on the alert [3].
What to watch
- Whether Check Point states coverage for R81.20 Takes 167 to 169 and R81.10 Take 191, which currently appear on neither list.
- Whether a LivePatch Take after 29 picks up the fix. A LivePatch fix would change the maintenance-window calculation for sites standardised on LivePatch.
- Whether Check Point publishes the uploaded payload or persistence mechanism. Either one would give defenders a file-level indicator instead of behavioural hunting.