If you host with 8Deploy, you are covered and no action is required. The rest of this post is for anyone who wants to know exactly what we did, including the part most hosts skip.
What was found
The PHP project published two vulnerabilities on 21 October 2026, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell. Both are rated 9.2 under CVSS v4.0, and both allow unauthenticated remote code execution. That means an attacker does not need a password, an account, or anything else from you.
Security researchers reported exploitation in the wild within days. Every PHP version before 8.5.12, 8.4.27, 8.3.36 and 8.2.35 is affected, along with older releases unless the vendor has backported the fix.
This was not a quiet advisory. Infrastructure and CDN providers wrote to their customers, and it was covered in the general technology press.
What we did
- 21 OctoberPHP publishes the fixed releases.
- 25 OctoberEvery PHP version on our platform updated to a patched build, including the backported fixes for the older versions some sites still run.
- 25 OctoberEvery PHP process restarted, and each one verified to be running the patched build before we called it done.
- 25 OctoberCustomer sites checked for unexpected files or activity. Nothing found.
Every site stayed online throughout. No customer had to do anything, and no customer was asked to.
Why restarting is the part that matters
This is the bit worth understanding, because it is where a patch quietly fails to be a patch.
Installing a PHP update does not protect a site that is already running. A running PHP process keeps using the copy of PHP it started with. Until it is restarted, it carries on serving requests with the vulnerable version, even though the server now reports the fixed one.
So a host can run the update, see the new version number, and still be serving the old code to every customer. The check and the reality disagree, and nothing visible says so.
On our platform every customer account runs PHP in its own isolated service rather than sharing one. That is good for isolation, and it means those services are not restarted automatically when the package updates. We restarted all of them, then read the version directly from each running process rather than asking the package manager what it thought it had installed.
Verifying the thing itself, rather than the thing that reports on it, is the whole job.
What we checked for afterwards
Because exploitation had been reported publicly, we looked for signs of it: recently changed PHP files in customer sites, unexpected network listeners, and processes running where they should not be.
We found no indications of compromise. We want to be precise about that sentence. It means we looked and found nothing, which is not the same as a guarantee that nothing happened. We would rather tell you what we actually know than offer a reassurance we cannot back.
If anything on your site looks wrong, tell us and we will investigate it properly rather than asking you to rule things out first.
What you should do
On your 8Deploy sites, nothing. It is handled.
If you run PHP anywhere else, a server of your own, another host, a staging box someone set up years ago, update it and restart the processes. The same trap applies there.
Sources
Questions
If you want to know anything else about how we handled this, or how we handle security generally, write to us. We would rather answer a direct question than have you guess.