# One Port to Root: Weaponizing Check Point Management CVE-2026-93616

Unauthenticated attacker spoofs the Check Point management server's own SIC identity to mint a session, then path-traverses a file upload to write /etc/cron.d as root, achieving RCE.

- Payout: Real-world hack
- Severity: critical
- Program: Check Point Security Management Server
- Analysis by: Bishop Fox
- Disclosed: 2026-10-01
- CVE: CVE-2026-93616
- Write-up quality: 9/10
- Original: https://bishopfox.com/blog/weaponizing-check-point-management-cve-2026-93616
- Library page: https://bugbountylibrary.com/r/blog%3Abishopfox-com-blog-weaponizing-check-point-management-cve-2026-93616
- Tags: area:cloud domain:infra impact:privesc impact:rce kind:incident platform:research sev:critical tech:java technique:chained technique:source-review vuln:auth-bypass vuln:file-upload vuln:path-traversal vuln:rce

**Target:** CPM SOAP web services (Apache CXF) on TCP 19009 under /cpmws/
**Root cause:** LoginSvcImpl.authenticateRemoteApplication trusts a caller-supplied CN= string as the client certificate DN without verifying a certificate was presented, and FileSvcRemote.uploadFileToServerFileSystem concatenates an uncanonicalized SOAP-header filename onto a temp dir, allowing ../ traversal to any absolute path as root.
**Steps:**
1. Read the server's own SIC distinguished name from the TLS certificate it presents on TCP 19009.
2. Call `loginNew` on `LoginSvcRemote` with the FwmAuthenticationInfo variant supplying `<application>,CN=<that SIC DN>` as a plain string; authenticateRemoteApplication accepts it and returns a READ_WRITE session.
3. Call `FileSvcRemote.uploadFileToServerFileSystem` with a destination filename containing `../` to overwrite an existing root-owned, non-world-writable file such as `/etc/cron.d/raid-check` with a crontab fragment running an attacker command as root.
4. Wait for the next minute boundary; cron executes the payload as root.
5. Payload writes stdout/stderr to an absolute path under the server's SMC_Files directory (release-specific), then `FileSvcRemote.downloadRawFile` retrieves it as an attachment under MTOM.
**How found:** Diffed patched vs unpatched builds; the bundle manifest showed upgrade_web_services.jar cited a single change ticket (most jars cite many), pointing at the jar declaring the vulnerable parameter. Recovered obfuscated strings decrypted at class load, spotting the vendor's own 'Failed to load allResourceFiles map from' log line, confirming the right code. Then diffed all 63 replacement jars, finding the login and write fixes in shared jars invisible to the single-ID heuristic.
**Exploitation:** No credentials needed. Attacker reads the server's published SIC name off the wire, forges a loginNew session claiming that identity plus a privileged application name, then uses the session to overwrite /etc/cron.d/raid-check with a crontab fragment. Cron fires on the next minute boundary, running the command as root; output is staged in SMC_Files and pulled back over the same session. PoC returned uid=0(admin) gid=0(root) on unpatched R81.10 and R82.10.
**Escalation:** Chained three defects: forged session mint (auth bypass), arbitrary root file write (traversal), and cron execution. Alternative vectors from the same write primitive: class loading in the upgrade service (/opt/CPupgrade-tools-*/jars/) and a config file re-read on a timer.
**Insight:** When a vendor advisory and patch disagree on scope, scope from the patch: diff every jar, not just the one the manifest ticket points at. Also, a login method that accepts a caller-supplied CN= string as a certificate DN lets an attacker impersonate the server to itself using the SIC name it publishes on the wire.

## Proof of concept (copied exactly from the original report)

**Forged loginNew session mint via CN string**

```
In its FwmAuthenticationInfo variant, loginNewaccepts the caller’s identity as a plain string: <application>,CN=<distinguished-name>. authenticateRemoteApplication reads the CN= half as the distinguished name it would otherwise have taken from a certificate, without checking that a certificate was presented at all. The name the server trusts is its own SIC name, which it publishes in the certificate it presents on 19009. The exploit reads that name off the wire, pairs it with the name of a privileged application, and gets a READ_WRITE session. The server authenticates the attacker as itself.
```

**Cron.d root write payload and output retrieval**

```
/etc/cron.d/raid-check is a weekly RAID maintenance task inherited from the Linux mdadmtool rather than anything Check Point ships. Overwriting it with a crontab fragment runs an attacker’s command as root on the next minute boundary. Cron requires a root-owned file that is not world-writable, so to get the permissions correct the file upload must overwrite an existing file rather than create a new one. No trigger request is needed since the cron daemon fires on its own. We chose this file over the other scheduled tasks on the box because a weekly RAID scrub is the least disruptive thing on it to borrow.
- Read the output back. The payload writes its stdout and stderrinto the server’s SMC_Files directory, named by absolute path because a cron job inherits none of the CPM process’s environment. That path is the one place the chain must know the product release. FileSvcRemote.downloadRawFile, over the same session, then retrieves the file as an attachment under MTOM
```

**Patch validation pattern for targetVersion**

```
public static final String VERSION_PARAM_PATTERN = "^[A-Za-z0-9._-]*$";
public static final String MODE_PARAM_PATTERN = "^[A-Za-z0-9_]*$";
```