Four Attribution Theories, One Attack Path: PHP2Shell on Check Point Gateways

What happened

The door. PHP2Shell is the name given to two memory-safety flaws in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS 4.0 and both exploitable without authentication. The first corrupts internal data when PHP runs out of memory part-way through setting up a request; the second leaves internal state alive after the request memory it points to has gone. PHP shipped fixes on 21 October, and watchTowr’s honeypots recorded exploitation the same day.[3] Many products embed PHP for their web interfaces. Singapore’s CSA lists affected products from Palo Alto Networks, Cisco, Citrix, F5, Siemens and Fortinet; Check Point’s gateways expose it through the Mobile Access portal.[2][4]

The campaign. Check Point’s hotfix for its gateways was available from 23 October. About a week later, on 30 October, activity from 130.94.19[.]204 hit Israeli organisations through vulnerable Mobile Access portals. A second, broader wave on 2 November went after organisations in several countries and sectors with no visible preference, which Check Point reads as opportunistic initial access. Some first-wave victims then saw the destructive stage. In Check Point’s own count, a couple of dozen unpatched systems were compromised.[1][2]

The chain, in Check Point’s words: “PHP2Shell provided initial access, followed by privilege escalation through the DynamicCLI interface, tracked as CVE-2026-123039. The attackers then deployed PHP web shells, the persistent TSGA backdoor, and its embedded TSProxy networking component.” Then: “The attackers pivoted from the gateway to a VMware ESXi host over SSH, deployed the destroy_v6 wiper, and left politically themed DREAM_ANNEXATION.txt notes during the destructive stage.”[1]

The path

One step per generic vulnerability, and a #7 at every moment foreign code starts to run:[5]

#2  →[Δt=instant]  #7  →[Δt=?]  #1 |[privilege][@portal_svc→@root]|  →[Δt=instant]  #7  →[Δt=?]  #7  →[Δt=?]  #7  →[Δt=?]  #7  →[Δt=?]  #4  →[Δt=?]  #7 + [DRE: Av]

Five of the nine steps are #7. On an appliance that is supposed to run only its vendor’s code, each of them is a moment at which an execution control could have said no, and each is a separate detection opportunity. Most of the Δt values are unknown; the sources give dates for the waves, not for the steps.

Two escalations, two clusters

The reports call CVE-2026-123039 a local privilege escalation, and that is exactly what it achieved: from the portal service account to root. But “privilege escalation” names what the attacker gained, not why it worked. TLCTC asks the second question.

Check Point describes the flaw as missing authorization in the DynamicCLI process: “any authenticated local user” can run arbitrary commands “by writing a single request to the socket.”[1] Nothing is corrupted, nothing overflows. The service does what it was built to do, running commands as root, for a caller it should have turned away. That is the scope of a designed function being wider than intended, and the TLCTC CWE mapping puts CWE-862 Missing Authorization under #1.[6]

Compare the escalation in CVE-2025-21333, the Hyper-V VSP bug: a heap overflow in a kernel driver, reached from user mode. Same outcome, local user to SYSTEM; different cause; #2.[7] And PHP2Shell itself, the step that gets the attacker in at all, is a memory-lifecycle flaw: #2 as well. Three ways to cross a privilege boundary, two clusters. The intra-system boundary operator |[privilege][@portal_svc→@root]| records the crossing, and it does not decide the cluster (R-INTRA-7).[5]

This matters for the defence. A memory-safety flaw is closed by patching and hardening the runtime. A missing authorization check is closed by putting the check in, and until then by keeping attacker code from ever being in a position to write to that socket. Both are needed here, and a single label, “LPE”, hides that they are two different jobs.

What is not a step

A path records successes, one generic vulnerability per step. Several things in the reports are real, but they are not steps:

• TSProxy “intercepts networking functions”, which sounds like #5 Man in the Middle. It is not. TSProxy hooks the appliance’s own processes so that “specially marked attacker connections” are handled while ordinary traffic passes.[1] That is concealed access for the attacker’s own channel, a feature of the #7 implant, not a position in someone else’s communication. If the attackers had used the gateway to read or alter the traffic of others, that would be a #5 step. No source says they did.
• TSGA’s capabilities: configuration theft, backup and snapshot persistence, process injection, binary firewall-log tampering.[1] These are what the implant can do. Where the sources show that it was done, the consequence is a DRE on that data. Check Point’s indicators include unexplained gaps in firewall logs,[2] which points at [DRE: I]: logs that no longer show what happened. Until an investigation confirms that for a given victim, it stays an expectation, not a path element.
• The note. DREAM_ANNEXATION.txt in every processed directory, no ransom demand. It is the attacker’s message, not a cause. It may feed attribution, and it may feed the business consequences. It is not a cluster.
• The wiper as a category. “Wiper attack” describes the outcome. The cause is the chain above; the wiper itself is one #7 with [DRE: Av] attached (Axiom III).

Where did vpxuser come from?

The jump from the gateway to ESXi was an SSH login with the vpxuser account, the service account vCenter uses to manage ESXi hosts.[1] The login is #4: a credential applied to authenticate is always #4, however it was obtained (Axiom X, R-CRED).[5]

How it was obtained is the open question. Neither Check Point nor the press coverage says. Axiom X requires the acquisition to be classified under the cluster that enabled it, so the record has a gap. But it is not obviously a missing step. If the secret was read from the gateway the attackers already owned as root, that is a confidentiality event on that gateway’s data within steps already on the path, not a new generic vulnerability. If it was taken from somewhere else, there is a step we cannot see yet. Because we cannot even say that a separate step happened, the path carries no ? here (R-UNRES-9); the question goes in the notes, as an open task for whoever handles one of these incidents.

Seven vendors, still not #10

PHP2Shell hit products from Check Point, Palo Alto Networks, Cisco, Citrix, F5, Siemens and Fortinet through a component none of them wrote. It is tempting to call that a supply chain attack. It is not one. Since v2.6, a #10 step requires that the trust artifact, or the party issuing it, was subverted before acceptance (R-SUPPLY).[5] Nobody subverted PHP. A legitimately supplied component had a flaw, and the flaw was exploited where the component runs: #2, at the portal.

The name gives it away: this is Log4Shell again. Two days ago this blog argued the same point from the risk-management side; a supplier’s flaw is third-party exposure, and it is not a supply chain attack.[8] The supply chain matters for the defence, because the fix has to travel from PHP through every appliance vendor to every customer. It does not change the cause.

Four theories, one path

Now back to the question Check Point cannot answer. The evidence for a China-nexus actor: TSGA and TSProxy are Check Point-specific components of PhiliKit, a toolkit ESET attributed in June 2026 to Armory Castle (formerly UNC5221); the infrastructure was LightNode VPS; scanning clustered between 12:00 and 09:00 UTC, Chinese working hours. The evidence against: a wiper, a focus on Israel, and a note that refers explicitly to the Israeli–Palestinian conflict.[1] Check Point: “Several scenarios remain plausible: the identified actor ran the entire campaign, acted solely as an initial access broker, or took part in a false-flag operation. It is also possible that the destructive activity served as a smoke screen.”[1]

This is Axiom IV at work: actor identity never determines classification.[5] The question for each step is which generic vulnerability made it succeed, and the answer does not change with the name on the operation. A missing authorization check is #1 whether a state service or a hired broker writes to the socket.

Attribution still matters. It shapes the response, the threat-intelligence picture and, in the smokescreen scenario, where to look for the data that may have left before the wiper ran. But it belongs beside the path, on the actor side, and it can stay open for months. The path does not have to wait for it. We have been here before: in the Chaos ransomware incident Rapid7 tied to MuddyWater, a state actor wore a criminal brand, and its seven steps were classified without the brand having to be true.[9]

The week that mattered

The most useful time interval in this story does not appear on the path. A Δt in TLCTC is a causal interval between two events of one attack, the window in which detection and response can still act. The gap between a fix being available and an attack is different: it is exposure, the time an organisation leaves its systems open to a known cause.

Here that gap was about a week: Check Point’s hotfix from 23 October, the first wave on 30 October.[1][2] For the PHP flaws themselves, watchTowr saw exploitation on the day of the fix.[3] An internet-facing portal on a security appliance is a #2 exposure with an exposure time measured in days at best. That is what makes “restrict the management and portal interfaces to trusted networks” the first control,[4] and the patch the second.

Consequences: evidenced and expected

The only data risk event the sources show directly is [DRE: Av] on the ESXi host: files overwritten with zeros, then deleted. Business risk events are not reported for any victim, so the path carries none. The ones to expect, listed with their TLCTC+ codes:[10]

• BRE-SVC.16 Critical Business Process Interrupted, causal, from Av on the virtual machines the host ran. The primary business event.
• BRE-ORG.13 Disaster Recovery Invoked, causal; then BRE-DATA.31 Restored With Loss or BRE-DATA.32 Permanently Lost, depending on the state of the backups.
• BRE-DATA.13 Control Material Exposed, if TSGA’s configuration theft is confirmed: gateway configurations and keys that open other systems.
• BRE-DATA.25, if the log tampering is confirmed: firewall logs that lose their value as evidence.
• BRE-REG.11 Mandatory Notification Obligation Triggered, normative, wherever an incident-reporting regime applies. A normative edge carries no Δt.

What to take from it

• Classify by cause, now. All nine steps are classified while the attribution is still open. Four theories, one path.
• “Privilege escalation” is an outcome. This one is #1, a missing authorization check, and it needs a different fix from the #2 flaws around it.
• A shared component is not a supply chain attack. PHP2Shell across seven vendors is #2 wherever it is exploited.
• Watch the #7s and the #4. Five executions on an appliance that should run only vendor code, and one credential that let the edge reach the hypervisor.