PHP2Shell: patched, restarted and verified
Security
PHP2Shell: patched, restarted and verified
On 21 October the PHP project shipped emergency fixes for two flaws that let an attacker run code on a web server without logging in first. Every site on the Eazi IT platform is now running the patched build, and we have read the version back off the running sites to prove it.
The two flaws are catalogued as CVE-2026-109618 and CVE-2026-109619, and the pair has been nicknamed PHP2Shell. Between them they affect essentially every PHP installation that serves web requests. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Our platform runs the 8.3 branch, so 8.3.36 was the target.
Why this one could not wait
Most vulnerability notices can wait for the next maintenance window. This one could not. There is no authentication step to get past, so anything reachable from the public internet was reachable by the exploit. Amazon’s threat intelligence team recorded an attempt against one of its honeypots on 17 October — four days before the flaws were made public, which means somebody had the details before the rest of us did.
The step that is easy to miss
Installing the patched package is not the same as running it. PHP keeps serving requests from worker processes that are already in memory, and those processes keep running the old code until they are recycled. A server can show a patched package and still be serving a vulnerable one. We have seen exactly that.
So the job is four steps, not one:
- Work out which PHP branch each site runs, and what the fixed version is for that branch.
- Apply the vendor patch.
- Restart every container, so no worker is still running the old code.
- Read the version back off the live site and record it with the date. Not the release note — the running site.
We did that across the platform today. Two sites in two separate customer accounts were checked by hand as independent confirmation, and both report PHP 8.3.36.
What this means if we host you
Nothing. That is the point of a care plan. Your site was briefly offline for a few seconds while its container restarted, and it is now on the patched build.
A small amount of legacy content still sits on an old shared-hosting account we are in the process of retiring. That hosting does not expose its patch level, so we cannot verify it — which is one of several reasons it is being retired. Nothing live and nothing client-facing depends on it.
The question worth asking your own provider
You should not have to know what CVE-2026-109618 is. That is the job you are paying a hosting and care plan to absorb. But you are entitled to ask the question, so ask it: what version of PHP is my site on, and when was it last patched?
A straight answer with a version number and a date in it is a good sign. “We keep everything up to date” is not an answer. And if the number comes back as 8.3.35 or lower, 8.4.26 or lower, or 8.2.34 or lower, it needs doing today.