Anatomy of a working exploit: CVE-2026-93616 on Check Point management servers

CISA added CVE-2026-93616 to the Known Exploited Vulnerabilities catalog on 2026-09-22, confirming in-the-wild abuse against Check Point Security Management Server, Multi-Domain Security Management Server, Log Server, Multi-Domain Log Server, and SmartEvent. The catalog description is precise about the primitive: a path traversal that lets an unauthenticated attacker upload and execute arbitrary scripts. Under the current KEV remediation directive, BOD 26-04 (Prioritizing Security Updates Based on Risk, effective 2026-06-10), federal civilian agencies must remediate KEV entries, and every operator of an internet-adjacent management plane should treat this as a same-week priority. This post shows what path traversal to script execution looks like in practice, using CVE-2026-93616 as the worked example, then contrasts it with a second KEV entry from the same week (CVE-2026-5430 in WSO2) so the class becomes recognisable rather than incidental.

What the primitive buys an attacker

Path traversal on its own is only a read/write oracle. Getting from that to code execution requires a landing zone the server will later interpret. On management appliances, three landing zones recur:

  1. A directory served by an interpreter (CGI, PHP, JSP, Python WSGI) where any file with the right extension executes on the next request.
  2. A configuration or job directory whose contents a supervisor loop, a cron-like scheduler, or a plugin loader ingests on a timer.
  3. A template or asset directory that a legitimate authenticated flow renders server-side, turning attacker-controlled bytes into attacker-controlled behaviour when a real user or internal daemon touches it.

CISA's KEV note for CVE-2026-93616 explicitly chains "upload" to "execute arbitrary scripts", which means the affected products expose at least one of those three landings to a request path that is (a) reachable pre-authentication and (b) resolves filenames that escape the intended directory. That combination is the whole exploit; everything else is packaging.

A reference-architecture PoC shape

Because the vendor advisory does not publish the vulnerable endpoint or a signature, I will not invent one. I can show the shape a working exploit for this class takes, so defenders can reason about their own telemetry. Assume a management plane exposing an HTTPS endpoint that accepts a multipart upload and stores the file under a per-request working directory. A canonical PoC against a reference host mgmt.example.com looks like this:

POST /portal/api/v1/attachments HTTP/1.1
Host: mgmt.example.com
Content-Type: multipart/form-data; boundary=----celvex
Content-Length: 412

------celvex
Content-Disposition: form-data; name="ticket"; filename="../../../../var/www/cgi-bin/z.cgi"
Content-Type: application/octet-stream

#!/bin/sh
echo "Content-Type: text/plain"
echo
id; uname -a; hostname
------celvex--

The two moving parts are the filename= value (the traversal) and the shebang payload (the landing). A vulnerable server accepts the filename verbatim, resolves it relative to a writable base above the CGI root, and writes an executable file into a directory the web server will later run. A plain GET /cgi-bin/z.cgi then delivers an unauthenticated shell as the web user. If the same daemon runs as root (management planes frequently do), there is no second stage.

Two details worth internalising:

How to tell whether you are exposed

For CVE-2026-93616 specifically, the questions are concrete:

  1. Is the management web interface (SmartConsole portal, SmartEvent, log server UI) reachable from anything other than a jump host? Anywhere it is reachable from an untrusted network, treat the host as pre-compromise until patched.
  2. Do you have request logs that record the raw URI and, ideally, multipart part headers? If yes, hunt for the traversal markers above against management endpoints. If no, that is the finding: you cannot answer the question, which under a KEV entry is itself an incident-response failure.
  3. Do you see child processes spawned by the management web server that are not on your expected list? A CGI written to disk and then executed shows up as an unexpected sh, perl, or python under the web server's process tree.

The Check Point advisory pairs this CVE with CVE-2026-85102 (improper certificate validation in Site-to-Site and Remote Access VPN on Security Gateway and Spark Firewall), a data-plane bug in a different product in the same portfolio. If you are already scheduling emergency change windows for the management servers, roll the gateway update into the same window.

Same week, same class: CVE-2026-5430

WSO2 API Control Plane, API Manager, Traffic Manager, and Universal Gateway were added to KEV on the same day (2026-09-24) with a near-identical description: path traversal leading to unrestricted file upload and remote code execution. The recurrence in a single KEV batch is the point. Path-traversal-to-RCE keeps working because it lives at the intersection of two components usually owned by different teams: the HTTP parser (often battle-hardened) and the storage layer (often a thin wrapper over os.path.join or its Java equivalent). The parser hands ../../../etc/foo to the storage layer intact, the storage layer resolves it, and neither team considers the join their responsibility.

The defensive corollary is a single invariant every upload handler should enforce and test: after computing the final absolute path, assert it is a descendant of the intended base directory and reject the request otherwise. In Python:

import os

def safe_join(base: str, user_path: str) -> str:
    base_abs = os.path.realpath(base)
    target = os.path.realpath(os.path.join(base_abs, user_path))
    if os.path.commonpath([base_abs, target]) != base_abs:
        raise PermissionError("path escapes base")
    return target

realpath on both sides is load-bearing: without it, a symlink inside base that points outside base defeats the check. commonpath beats startswith because /var/data-evil starts with /var/data and would slip through a naive prefix test.

What to do this week

Patch the six KEV entries added in the run-up to 2026-09-25 in the order your exposure dictates, not the order they appeared. For most estates that means Check Point management first (CVE-2026-93616), then F5 BIG-IP APM (CVE-2026-94127, unauthenticated heap overflow to RCE where an access policy plus OAuth profile is bound to a virtual server), then WSO2 (CVE-2026-5430), then Arista VeloCloud Orchestrator (CVE-2026-93952), then Adobe Commerce (CVE-2026-71362), then the Check Point gateway VPN bug (CVE-2026-85102). While the change windows are booked, add the upload invariant above to your secure-coding standard and turn it into a unit test in your internal frameworks so the next path traversal in your own code fails a pipeline instead of an advisory.

Verifiable security.