Two critical, unauthenticated remote code execution flaws in PHP, collectively nicknamed PHP2Shell (CVE-2026-109618 and CVE-2026-109619), were patched today. They let an attacker run code on almost any PHP-driven web server before a single line of your application executes. Patch now: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. But patching closes the door only for hosts that weren’t already walked through. This post explains how the attack works, shows what it does to a WordPress site in a lab, and demonstrates where file integrity monitoring — the discipline behind CimTrak — catches the attacker’s very next move and reverses it.
On October 20, 2026, the PHP security team put out an unusual advance notice: emergency releases were coming the next day for two critical vulnerabilities. That kind of pre-announcement is rare, and it was warranted. The flaws, publicly demonstrated as an exploit chain called php2shell by researcher Kirill Firsov (with credit to LCFR and Calif.io), allow unauthenticated remote code execution against essentially any server that uses PHP to handle web requests.
The numbers tell the story:
PHP branches 8.1 and older are end-of-life and will not receive fixes. If you are on one of those, the upgrade is no longer optional.
A quick, important clarification on mitigations: in the hours before release, people floated INI-level workarounds such as disabling session upload progress. PHP maintainers publicly shot that down — INI settings do not neutralize these bugs. CERT-EU (advisory 2026-018) recommends isolating internet-facing apps from the public network where you genuinely cannot patch yet. Cloudflare has pushed WAF rules as a stopgap for traffic that passes through them. None of these is a substitute for the update.
Both vulnerabilities live in the plumbing that PHP uses to set up and tear down each web request — not in any application code you wrote. Based on public reporting, they’re memory-safety bugs:
Chained together, those primitives give an attacker enough control over the interpreter’s memory to execute their own code. The exploit is especially dangerous under mod_php, where a crafted request can trigger it before any application code runs — meaning no plugin, no firewall rule in your app, and no authentication check ever gets a say.
Here’s the part that matters for defenders, and the honest center of this whole post:
The exploitation itself — stages 1 through 3 — happens entirely in process memory. Nothing touches the disk. No file integrity tool on earth will see that part, and any vendor who tells you otherwise is selling you something. The only thing that stops stages 1–3 is the PHP patch.
So why write a post about file integrity monitoring at all? Because stage 4 is where attackers make their money.
Code execution in a short-lived PHP worker is powerful but ephemeral. Workers recycle. Memory gets wiped. To turn a fleeting foothold into a durable compromise — and to actually do anything — the attacker almost always writes to disk:
The target is a stock WordPress 6.7 install — 3,225 files. After simulating the post-exploitation stage, the front page tells the story a visitor would see:
Figure 2: The lab WordPress site after the simulated intrusion: a defacement where the homepage should be.
Behind that defacement, five changes landed on disk:
Quiet, specific, and exactly the kind of change set that blends into a busy site. Nothing here would trip a signature-based scanner tuned for known malware hashes, because these payloads are bespoke. What they can’t hide from is a system that knows precisely what every file is supposed to look like.
CimTrak’s model is change, measured against a trusted baseline, in real time. You establish an authoritative snapshot of a system’s files — hashes, sizes, permissions — and from then on any deviation that doesn’t match an approved change ticket is flagged the moment it happens, with the file, the operation, and the responsible process attached.
To demonstrate that behavior faithfully, the lab runs a minimal integrity monitor that works the same way CimTrak does in principle: baseline, then detect drift. Here is the real output from the lab after the simulated intrusion — not a mockup:
Figure 3: Real integrity-scan output: 5 change events (2 added, 3 modified), each with before/after SHA-256 fingerprints.
Five events. Two added files, three modified, zero false positives, each with its before-and-after SHA-256 fingerprint. The web shell buried four directories deep in uploads is called out as plainly as the defaced index.php.
In a production CimTrak deployment, the same five events surface in the console with severity, the user and process responsible, and one-click response actions. Here’s an illustration of how that change event would present:
A closer look:
Figure 4: All rogue changes that have been written to the disk by the php2shell exploit have been detected by CimTrak in realtime. This screen shows CimTrak in the monitoring mode. CimTrak can also be configured to automatically rollback these unexpected changes.
The point this makes for a PHP2Shell scenario: even though the exploit was invisible, the attacker’s first durable action was not. Integrity monitoring collapses the attacker’s dwell time from “until someone happens to notice the defacement” to “the instant the web shell hit disk.”
Detection is half the value. The other half is getting clean again fast. Because the baseline stored a trusted copy of every file, recovery is deterministic: remove what the attacker added, restore what they changed, and re-verify. The lab does exactly that, and confirms the system is back to its 3,225-file baseline with zero drift:
This is where a platform like CimTrak earns its place in an incident: instead of rebuilding a host from scratch and hoping you found every backdoor, you roll the file system back to a cryptographically verified good state and know — not hope — that nothing the attacker left behind survived.
A vendor post that only lists wins isn’t worth your time, so here’s the boundary:
Within those limits, the value is real and specific: for the overwhelmingly common case where an attacker converts code execution into on-disk persistence, integrity monitoring turns a silent compromise into a timestamped, attributable, reversible event.
Patching stops the exploit. Knowing the moment anything on disk changes — and being able to put it back — is how you make sure a missed patch window doesn’t quietly become a resident attacker.