When the Interpreter Is the Vulnerability
On October 21 the PHP project disclosed two critical vulnerabilities, collectively nicknamed PHP2Shell: CVE-2026-109618 and CVE-2026-109619, each rated 9.2 on CVSS v4. They allow an unauthenticated attacker to execute code on a PHP installation serving web requests before any application code runs. Read that clause again, because it defines the whole day: before any application code runs. The web application firewall, the hardened login, the carefully audited plugin list, every protection that lives in or above the application was irrelevant. Security vendors reported exploitation beginning the same day.
We maintain client applications on several stacks, and three of them run PHP: one enterprise site on OpenDXP and two WordPress portal properties. A fourth property, the same client's main marketing site, needed nothing, because it no longer includes PHP anywhere in its stack. By the end of the afternoon all three applications were patched, verified, and restored, with total public downtime of about 75 minutes for the OpenDXP site and about 60 for the portals, all of it inside controlled maintenance windows. The forensic reviews on every site came back clean. Here is what the day taught, in the order it taught it.
Zero Execution Beats Zero Ingress
The reflexive move when you cannot patch instantly is a maintenance page, and a maintenance page is enough to stop external exploitation. We went one step further on every site: the PHP processes themselves were stopped, not merely hidden behind a 503. For a plugin or application vulnerability that distinction is pedantic. For an interpreter vulnerability it is the whole point, because it also closes anything process-local: scheduled tasks firing internal requests, cron hitting the application from localhost, anything a prior foothold might have had queued. From the moment we learned of the advisory, no unpatched PHP was reachable from any path, network or otherwise.
Run the Forensics While the Engine is Cold
Patching rewrites files and restarts processes, which is to say it disturbs the forensic baseline. So the compromise sweeps ran during the maintenance windows, before the patches went on, while the filesystems were quiescent. It cost nothing: we were waiting on upstream artifacts anyway. The WordPress sweep ran fifteen checks per site, from core file integrity (3,339 files against the published checksums, zero mismatches) through webshell signatures, option-table payload patterns, admin account audits, .htaccess integrity, and host-level persistence. The OpenDXP review ran twelve, across request logs, application logs, filesystem, database, and host.
The OpenDXP review also shows what convergent evidence looks like when the absence of something is the signal. Exploiting these flaws destabilizes PHP worker processes; seven days of logs showed zero worker crashes. Every PHP process was destroyed and replaced during patching, so a memory-only payload could not have survived. A surviving compromise would therefore need filesystem, database, or host artifacts, and targeted sweeps of all three found none. Three independent lines, one conclusion.
Verify the Patch You are Rushing to Install
A patch applied within hours of release deserves more suspicion, not less, and last quarter's npm supply-chain compromise taught everyone where breaches come from now. For the OpenDXP site, the patched PHP was built from the official source release, with the tarball's checksum cross-confirmed from two independent channels: php.net's published sums and the checksum pinned in Docker's official-images repository. The build pipeline halts on any mismatch, and we watched that control actually fire once during the day; investigation traced the discrepancy to a benign configuration collision, but the halt is the point. Only the PHP engine changed. Same OS, same extensions, same configuration.
Murphy Audits your Dependencies at the Worst Moment
The WordPress rebuild produced the day's most instructive failure: mid-emergency, pecl.php.net started returning HTTP 500, taking two required PHP extensions with it. An unrelated upstream outage, during the one hour we needed the registry most. The workaround became the permanent fix: both extensions are now vendored as SHA-256-pinned tarballs fetched from their GitHub releases and built directly, so the container build no longer depends on PECL's uptime at all. An emergency that leaves the system more reproducible than it found it is a good emergency.
Results and Gaps
Every claim above has a number attached. The OpenDXP site came back to a full crawl of all 1,613 published URLs returning healthy responses. The portals came back with their extension sets bitwise-identical to pre-upgrade, zero PHP errors in the post-restart logs, and a tagged rollback image retained on disk. And the reports are honest about what was not done: a binary attack log was not decoded offline, a database binlog diff was not performed, and one premium plugin's file integrity was taken on trust. Naming the gaps is part of the review; a forensic report with no residual uncertainty is describing the reviewer, not the system.
The Playbook is the Product
One advisory, two platforms, three applications, one playbook: assess exposure, take execution to zero, sweep while cold, verify the artifact you are installing, restore behind verification, keep the rollback anchor. None of it is exotic. All of it has to already exist on the day the interpreter itself is the vulnerability, because that day gives you no time to invent it. The sites that fared best in this story were the ones with the least surface: the static site was never at risk, and the portals that bind their process managers to loopback had one of the CVEs not even apply. Subtraction is still the cheapest security control we know of.
