Security

Critical PHP vulnerabilities, already patched on every 8Deploy site

25 October 2026 · 4 min read · 8Deploy is a service of WeActive8

Two unauthenticated remote code execution flaws were published on 21 October. Here is exactly what we did about them, and why installing the update is only half the job.

Summarise this article with:

AI summary

Two unauthenticated remote code execution flaws in PHP were published on 21 October. Every 8Deploy site was patched, every PHP process restarted, and each one verified. Customers need to do nothing.

  • CVE-2026-109618 and CVE-2026-109619 are both rated 9.2 under CVSS v4.0 and both allow remote code execution with no password and no account.
  • Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older release lines are covered by vendor backports where the version number stays the same and only the build date moves.
  • Installing the update is only half the job. A running PHP process keeps the copy of PHP it started with, so a host can patch, read back the fixed version, and still be serving the old code.
  • Every PHP service on the platform was restarted and then checked by reading the binary from the running process itself, not by asking the package manager.
  • Customer sites were checked for recently changed files, unexpected listeners and stray processes. Nothing was found, which is not the same as a guarantee.

This is the write-up we would want to read if we were the customer. The interesting part is not the patch, it is the restart: the step that turns an installed fix into a live one, and the step that is easiest to skip without anything appearing to be wrong.

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.

Frequently asked questions

No. We updated PHP on every service that runs your sites, restarted every PHP process and verified each one is running the patched build. The work is already done.

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older release lines are fixed through backports from the distribution maintainer, where the version number stays the same and the build date changes.

A running PHP process keeps using the copy of PHP it started with. Until it restarts it carries on serving requests with the vulnerable version, even though the server reports the fixed one. That is how a host can install the update and still be serving the old code.

We checked for recently changed PHP files, unexpected network listeners and processes running where they should not be, and found no indications of compromise. That means we looked and found nothing, which is not the same as a guarantee. If anything on your site looks wrong, tell us and we will investigate it.

Update it and restart the processes. The same trap applies anywhere PHP runs, including a staging server someone set up years ago and forgot.