Destructive Check Point gateway attacks chain PHP2Shell with CVE-2026-123039 root escalation

Destructive chain hits Check Point gateways

A security analysis published on dev.to by Satyam Rastogi, originally posted to satyamrastogi.com, describes destructive attacks against Check Point Security Gateway appliances built on a two-stage compromise. According to the write-up, attackers first planted a PHP web shell dubbed PHP2Shell on web-facing gateway components, then exploited CVE-2026-123039 to escalate to root. The combined result was total control over perimeter security devices, opening the way to lateral movement and data exfiltration inside protected networks.

Stage one: web shell for initial access

PHP2Shell is described as a web shell that abuses PHP execution on compromised servers and gateway appliances. The analysis presents three probable routes to the initial foothold: management interfaces exposed to the internet, such as the Check Point WebUI or SmartDashboard; PHP-based components in the administration panels that were themselves vulnerable; and configuration endpoints without adequate input validation. The technique maps to MITRE ATT&CK T1505.003, the standard web shell pattern. Once in place, the shell let the attacker run commands inside the gateway's user context, typically an admin or daemon account, and stay persistent through either a reverse TCP connection or follow-up HTTP requests.

Stage two: CVE-2026-123039 to root

From that foothold, the attackers reportedly triggered CVE-2026-123039 to raise the process to UID 0. The source is candid that detailed CVE information is not yet available and offers candidate mechanisms rather than confirmed ones: a kernel race condition or use-after-free flaw, unsafe privilege separation in Check Point daemon processes, or file descriptor inheritance problems during gateway initialisation. Depending on the actual mechanism, the escalation would map to ATT&CK techniques covering access token manipulation or abuse of elevation control. With root in hand, the attacker could load kernel modules, sidestep packet filtering and rewrite audit records.

Destruction after the break-in

The post-compromise behaviour was deliberately destructive. The analysis lists likely actions including deleting or corrupting firewall rules so enforcement quietly stops, wiping logs and audit trails, corrupting encrypted backups, rolling configurations back to insecure states, and stripping host-based IPS and IDS signatures. These patterns align with data destruction and indicator-removal techniques commonly seen in campaigns against critical infrastructure.

Detection and hardening

For detection, the write-up points to network signals such as encoded HTTP POST requests hitting admin, API or PHP endpoints, unexpected outbound connections from the gateway that could be reverse shell callbacks, anomalous DNS lookups, and bursts of firewall policy changes from a single session. Host-side, defenders should watch for new PHP files in /tmp and /var/tmp, PHP processes spawning shells or tools such as curl and nc, privilege escalation attempts, and access to /dev/mem. Proposed SIEM alerts include an admin login followed by PHP execution within ten seconds, more than fifty policy modifications inside a five-minute window, and log deletion immediately preceding a system restart.

The immediate mitigations are conventional but urgent: apply the Check Point advisories that address CVE-2026-123039, audit gateway admin accounts for unauthorised changes, restrict management access to bastion hosts rather than the open internet, and capture memory and filesystem images for forensics before patching. Longer term, the analysis recommends multi-factor authentication on all administrative accounts, real-time audit logging to a SIEM, privileged access management for gateway credentials, isolated management networks, weekly vulnerability scans of gateway endpoints, a 30-to-90-day threat hunt through historical logs, and verified backup restore capability.

How solid are the details

One caveat deserves emphasis: this is a single analyst write-up, not a vendor advisory. The summary presents the attack chain as fact, but the technical sections hedge repeatedly, framing the initial-access vectors as probable and stating outright that no detailed CVE information exists. Administrators should treat the chain as a plausible and useful model while cross-checking official Check Point security advisories.

Why it matters

Firewalls and gateways sit at the trust boundary, and this incident, as described, shows why they deserve domain-controller-grade protection: a compromised gateway hands an attacker network access without ever touching an endpoint, and a web shell combined with a kernel-level escalation is enough to take the device over completely. The story is also a reminder that security appliances are themselves software and should sit near the front of the patch queue, ahead of general endpoints. Because attackers used log deletion to cover their tracks, immutable audit logging shipped off the appliance becomes an essential control, not an optional one. Finally, policy changes and admin account creation should be verified through channels separate from a management interface that may already be under attacker control.