PHP2Shell Emergency Fix: We Patch Your PHP, Test the Site and Check for Intruders

The patch shipped October 21. Your server may not have it.

On October 21, 2026, the PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to close two critical holes, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. Wiz Research, which found them and named them PHP2Shell, says an anonymous visitor can, under the right conditions, run code on the server. The flaws sat in PHP for more than a decade. With the help of AI models, one researcher found them in about a week. The full story is on the PHP2Shell hub.

Here is the awkward part. A release on php.net does nothing for your site until it is installed on the machine that serves it. On shared hosting, the host has to ship the new build and someone has to select it. On a VPS, someone has to run the update and restart PHP. In Docker, someone has to rebuild the image and redeploy. Meanwhile the host's status page says all systems normal, which is true in the sense that the systems are running normally, vulnerable version included.

The PHP project's own release notes are blunt: "There are no complete mitigations, updating is the only safe choice." Security firms reported attack attempts against their sensors within a day of disclosure. Confirmed compromises had not been publicly reported as of October 22, and that can change any day. If you are not sure where you stand, find out whether you are affected first, or let us find out for you.

Nor is this a one-week story. In a CNBC interview on October 23, CrowdStrike's chief executive said we will see a lot of breaches in the coming months from this vulnerability. A breach that surfaces in February usually starts with a server someone meant to update in October. The cheapest day to patch is the day you read about it.

A security release is a promise. It becomes a fix when it reaches your server.

Seven moves, in the order we make them

Emergencies reward a fixed sequence. We do not improvise on a live server, and we do not update first and back up later. This is the order, and each step produces something you can see.

1. 1

   Read the server

   We record the exact PHP version, how PHP is wired to the web server (PHP-FPM, mod_php, LiteSpeed and so on) and who controls the build: you, your host or a container image. Risk is highest for mod_php, per the PHP project.

2. 2

   Take a full backup

   Files and database, stored off the server, before anything changes. If the site was already tampered with, this copy is also the evidence.

3. 3

   Install a fixed release

   We move the site to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12. If the host cannot offer one, we move the site to a plan or host that can. On a VPS we update the packages and restart every worker; in Docker we rebuild and redeploy.

4. 4

   Hold the line if the update must wait

   When a theme or plugin will not survive the jump today, we apply the PHP project's interim settings and request limits, then schedule the update. These narrow the attack paths; they do not close them.

5. 5

   Test the site like a customer

   Home page, forms, checkout, logins, search and admin, on desktop and phone. Themes, plugins and page builders that choke on newer PHP are the usual casualty, and we fix or replace what breaks.

6. 6

   Look for footprints

   We check for the warning signs Wiz described and for the ordinary marks of a break-in: new PHP files in uploads, unknown admin users, strange scheduled tasks.

7. 7

   Clean up and report

   If we find an intruder, we remove the code, close the way in and rotate the passwords and keys the server could read. Then you get a written report.

Fixed prices, paid on the page

Most of our PHP2Shell work lands in one of four fixed-price repairs from our Fix It Now menu. You pick the tier, pay on the page, and we start within one business day of payment. If we can't fix it, you get a full refund. Those are the only two promises we make, and we keep them.

The fixed prices cover WordPress, because WordPress problems repeat often enough to price in advance. Other PHP sites vary too much for that, so we look first and quote after. Old sites deserve their own conversation: if yours runs PHP 7.4 or 8.0, the PHP project ships no release for it, and our end-of-life PHP guide explains the choices before you spend a dollar.

When the update has to wait until Monday

Sometimes the honest answer is not today. A membership plugin abandoned in 2019 will not run on PHP 8.2, and the business cannot lose logins on a Thursday. In that case we buy time with the measures the PHP project lists, which, in its words, "reduce exposure to specific attack paths but do not make an installation safe."

• Session upload progress off. We set `session.upload_progress.enabled = 0` in php.ini, the FPM pool or server config that applies before request parsing, then restart every worker. It blocks the confirmed session paths, not every variant.
• Smaller request bodies. `post_max_size = 8M` for sites without uploads, `32M` where uploads are needed, with `upload_max_filesize` set below it.
• Limits at the web server. Caps on request size, field count, multipart parts, headers and nesting depth, including requests that arrive without a usable Content-Length.
• A memory setting the app cannot override. `php_admin_value[memory_limit] = -1`, paired with a container or cgroup memory limit, because an allocation failure can still reach the vulnerable path.
• A firewall rule in front. Cloudflare, Fastly, Google and others published protections. A rule buys hours or days. It does not replace the update.

Hiding error messages does not help, and a WordPress security plugin cannot help either: the bug lives in PHP, below WordPress, where no plugin can reach. The complete list, with the fine print, is on our temporary mitigations page. We treat every interim setting as a dated IOU, and we put the date in writing.

Our checklist for you is short

Speed in an emergency depends less on our typing and more on access. The fastest jobs are the ones where the right login arrives with the payment and one person can say yes.

On shared hosting, the host controls the PHP build, so part of our job is getting the host to say, in writing, which version your site runs and when it was installed. Our guide to patching on shared hosting has the exact wording we use.

Four things owners tell us before they hire us

CrowdStrike's analysis adds a wrinkle worth knowing: on Apache with mod_php, a single unauthenticated POST request can be enough, and the attack traffic can come back as ordinary 200 responses. A clean access log is not an alibi. That is why our check reads the PHP and web server error logs, worker restarts and the file system, not just the visitor log.

Make the next one someone else's 2 a.m.

PHP2Shell will not be the last critical PHP release. PHP 8.2 itself reaches end of life on December 31, 2026, ten weeks from now, and gets no security fixes after that. The owners who slept through this week were the ones whose updates were already somebody's job.

Our hosting and maintenance plans make it ours: tested updates, backups stored off the server, security and uptime monitoring, and small edits, with no long contract. There is no published price; we quote after seeing the site. For the deeper version of the same question, there is a way to stop worrying about PHP on your public site altogether: a Next.js front end with WordPress kept private behind it, or a full move to our own content system.