We patched PHP2Shell (CVE-2026-109618) across 634 real servers. Here is the before and after
PHP2Shell is the big one this week. On October 21, 2026, the PHP team shipped emergency patches for two critical remote code execution flaws in PHP core, CVE-2026-109618 and CVE-2026-109619. PHP rated them 9.2 on CVSS v4.0; watchTowr, which reproduced the first one, rated them a flat 10.0. Both can let an attacker run code on a web server with no authentication. The details leaked on October 20, a day before the planned disclosure, which forced the release forward. Patched versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. mod_php is the highest-risk configuration. Config changes reduce exposure but do not make a system safe. Updating is the only complete fix. Knowing about the CVE is the easy part. You probably saw it within the hour. The hard part is operational: do you know every machine running a vulnerable PHP, can you push the exact fixed version to all of them fast, and can you prove afterward what you patched and when? So instead of talking about it, we ran it. The te
PHP2Shell is the big one this week. On October 21, 2026, the PHP team shipped emergency patches for two critical remote code execution flaws in PHP core, CVE-2026-109618 and CVE-2026-109619. PHP rated them 9.2 on CVSS v4.0; watchTowr, which reproduced the first one, rated them a flat 10.0. Both can let an attacker run code on a web server with no authentication.
The details leaked on October 20, a day before the planned disclosure, which forced the release forward. Patched versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. mod_php is the highest-risk configuration. Config changes reduce exposure but do not make a system safe. Updating is the only complete fix.
Knowing about the CVE is the easy part. You probably saw it within the hour. The hard part is operational: do you know every machine running a vulnerable PHP, can you push the exact fixed version to all of them fast, and can you prove afterward what you patched and when? So instead of talking about it, we ran it.
The test
We stood up 634 servers on AWS: 600 Debian web servers running the vulnerable PHP, and 34 Windows servers.
Gardience checked every machine against Debian's own security data. It found PHP2Shell (CVE-2026-109618) on all 600 web servers, with a fix available, and correctly marked the 34 Windows servers as not exposed.
No guessing which boxes are affected. It is a lookup.
One governed patch
This is where a fleet either holds together or turns into a weekend. We patched all 634 through a single governed action:
- A team member requested the patch.
- A second person approved it. The requester cannot approve their own change.
- Gardience patched the whole fleet.
- The rescan came back: 0 machines exposed, every web server on the fixed PHP.
- Linux and Windows, one view, one action, with a person in the loop.
The part your auditor asks about
Every step is written to a tamper-evident audit log: who requested it, who approved it, the exact versions installed, and the before and after scan. When the incident review asks "prove you patched CVE-2026-109618 across the fleet, and when," that is a report, not an archaeology dig.
Right now, whatever you run
Patch PHP today. 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Prioritize mod_php and anything internet-facing. Config tweaks are not a fix, and the proof-of-concept is already public, so the window is now.
And if the honest answer to "can we push this across the whole fleet fast and prove it" is no, that is the thing worth fixing before the next 10.0 lands, because there is always a next one.
Gardience is at gardience.com.
