PHP2Shell: The Critical PHP Flaw Taking Sites Offline, and Who Actually Patches It

Last updated: October 22, 2026

By Mike Carter, Managing Director, KORE1

PHP2Shell is a pair of critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, that let an attacker run code on a web server without logging in, and the only complete fix is upgrading to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Both score 9.2. PHP shipped the patches on October 21, 2026, and a UK minister told the House of Lords that 32 government services were unavailable while teams applied them.

Thirty-two. That’s the count a Lords minister gave this week, plus four more services that were only partly available. She called the outages “precautionary measures taken to protect systems while security updates and mitigations are applied,” according to LBC’s report of the statement. A Downing Street spokeswoman added that it “does not mean they were hacked.” Fair enough. Offline and breached are different problems.

The UK’s National Cyber Security Centre went further. Update PHP now, it told organizations, or consider taking the site offline until you can.

I don’t patch servers. I run the business side of a staffing firm, which means I hear about these events about two weeks late, from a CTO who has just found out that the hard part of a critical PHP vulnerability isn’t the fix. It’s finding someone with the hours and the access to apply it. We place people through our PHP developer staffing desk and our cybersecurity staffing team, so weigh everything below with that in mind.

Video chapters

• 0:00 — Intro
• 0:19 — What PHP2Shell Is
• 1:02 — Which PHP Version You’re Running
• 1:59 — Who Actually Patches It
• 2:49 — The Staffing Math Nobody Budgeted
• 3:59 — Questions About PHP2Shell
• 4:18 — Start With the Inventory

What PHP2Shell Is, in Plain Terms

PHP2Shell is the nickname for two vulnerabilities in the PHP engine itself, not in any one website or plugin. Each lets an unauthenticated attacker run commands with the permissions of the web server process. Because the flaw lives in the runtime, every site on an unpatched PHP version is exposed, whatever it was built with.

The foundation cracked. Not the house.

The row that scares me is the first one. PHP’s own advisory says the riskiest setup is Apache with mod_php, where, as BleepingComputer quotes PHP, “an unauthenticated request can trigger the attack before any application code runs.” Read that twice. Your carefully patched WordPress, your tidy Laravel app, your web application firewall rules written for last year’s attacks. None of it matters.

PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are on the affected list too, per Qualys’s breakdown. PHP lists a few interim settings, turning off session upload progress being the best known, and then says in the same breath that they “do not make an installation safe.” Updating is the only complete answer. Everything else is a delay.

Which PHP Version Are You Actually Running?

Old versions don’t all get the same treatment, which is more annoying than “no fix at all.” Check yours first.

Source for the table is PHP’s own advisory and its release notes. One more wrinkle. Public reporting suggests every version from PHP 5 onward is affected, so an old box that isn’t on any list is not an old box that’s safe.

How many sites does that touch? W3Techs showed PHP on 69.3% of sites with a detectable server-side language as of October 22, 2026. Among those, 65.3% run PHP 8, 26.9% run PHP 7, 7.7% still run PHP 5, and 0.1% run PHP 4. Add PHP 7, 5 and 4 together and 34.7% of PHP sites run a major version the project stopped supporting years ago. W3Techs lumps 8.0 and 8.1 in with “8,” so the real number of unsupported installs is higher than that, and nobody I’ve read will say by how much.

That’s a lot of boxes.

Why Sites Went Dark Instead of Just Patching

No middle option. A routine PHP security update gets a maintenance window and a rollback plan. This one got an afternoon. PHP gave advance notice on October 20 that a release was coming on the 21st, and said it would move sooner if details leaked or exploitation showed up. Details leaked anyway, and the attempts started before the patch did.

Amazon’s threat intelligence team recorded an exploitation attempt on its MadPot honeypot on October 17, four days before the patches, from an IP address tied to a commercial anonymization service, as Help Net Security reported. Cloudflare’s CTO said early attacks were showing up and described the firewall rules his team shipped as temporary. Early on, SecurityWeek noted that watchTowr and Huntress had not yet seen real-world exploitation. The early reports disagreed, and SecurityWeek’s later updates came down on the side of the attempts being real.

So for a team with a vulnerable box and no patch capacity, “offline” wasn’t drama. It was the only brake available. Somebody still has to make that call, explain it to the business, and then reverse it, and that somebody is usually the same person who was supposed to be patching.

Who Actually Patches It

Three kinds of owners, and they don’t have the same problem.

• On a managed WordPress or hosting plan, the host owns the PHP runtime. Updating WordPress or your plugins does not update PHP, as Malwarebytes points out. Your whole job is one email asking the host to confirm the fix is installed, not scheduled. If that comes back yes, you may need nobody from us.
• Self-managed servers and containers belong to whoever set them up, and that person has frequently left. Containers are the sneaky ones. A base image pinned two years ago keeps shipping the PHP it was built with, whatever the host operating system is doing.
• Vendor appliances are a waiting game. Palo Alto confirmed that all versions of PAN-OS and Panorama are affected with no fixed release yet, while Fortinet and Cisco were still checking 12 and 31 products respectively, per the same Help Net Security update. You can’t patch what the vendor hasn’t shipped. You restrict exposure and keep checking.

Different owners. Different clocks.

Now the part that never makes the headline. The Bureau of Labor Statistics counts 314,340 network and computer systems administrators in the United States, with a May 2025 median wage of $99,130. VirusTotal estimates more than 5.1 million PHP hosts are exposed online, according to BleepingComputer’s coverage. Those two numbers don’t divide into each other, because the hosts are worldwide and the BLS count is U.S. only and plenty of hosts share one operator, but put them side by side anyway and you can see why patch week is a queue, not a task.

A patch isn’t one command.

Qualys’s advice is to find every PHP installation, including containers and parallel branches, then confirm the running workers actually use the patched runtime, then restart all of them, then rescan. Finding every installation is the step that eats the first two days. Easily. Picture a regional distributor with an order portal on PHP 7.4. Ask where PHP runs and you’ll hear one server. Then someone greps the load balancer config and finds the marketing site, a forgotten staging box and a customer-facing PDF generator, all on PHP too.

That’s an illustration of how these searches tend to start, not a named client. The pattern is the real part.

When the Upgrade Is the Project

A patch release inside the same line, say 8.3.35 to 8.3.36, is mostly an operations job. Jumping from 7.4 to a supported release is a development project, and the PHP 8.0 migration guide lists why.

The function create_function() was removed. So was each(), which older order-entry code sometimes leans on, and which turns a working page into a fatal error on 8.x. Comparisons between numbers and strings changed too, so 0 == "foo" was true in PHP 7 and is false in PHP 8. If a permissions check or a login routine leans on loose comparison, the answer it gives can quietly change.

Several operations that used to emit a warning now throw an error.

None of this is exotic. A good PHP developer can read a legacy codebase, search it for the removed functions and the loose comparisons, and tell you in an afternoon whether it’s a two-week job or a two-month one, which is the single most useful thing you can buy this week. That afternoon is scarce. We’ve covered the cost and sequencing of modernizing legacy applications before. This week it’s just urgent.

The Staffing Math Nobody Budgeted

Here’s how I’d split the work, and what kind of hire fits each piece. The contract and direct hire labels are my recommendation from watching IT searches, not a rule.

Four seats. Not forty. Pay shifts the picture. BLS puts information security analysts at a $129,180 median and software developers at $135,980, both for May 2025, and our salary benchmark assistant will price a specific seat and metro before you post it. Contract help costs more per hour. For work with an end date, it’s often still the cheaper route.

The counterintuitive part is the order. Most teams go looking for a “PHP security expert” first, which feels right, and then spend a week finding out that the expert needs someone to tell them which servers exist, who owns them, and which ones the business would genuinely miss if they went dark. Don’t start there. Hire the person who can answer one question, what runs where. Every other hire is guessing until that question has an answer.

On speed, our own numbers are the most useful thing I can give you. Across 1,997 KORE1 contract starts, the median gap between an accepted offer and day one was 3 days. For permanent IT seats, our average time to fill runs 17 days, and we track a 92% twelve-month retention rate on placements. A contract staffing engagement is how you get a patch lead before the weekend. It doesn’t replace the owner you hire after.

What We Still Don’t Know

A few honest gaps. Nobody has published a clean count of compromised servers, the UK figure comes from one minister’s answer in the Lords with no list of which services were affected, and the Qualys breakdown doesn’t spell out the affected version ranges. The 5.1 million figure is an estimate of exposed hosts. Not vulnerable ones.

None of that changes what you should do first. Vendors will keep issuing advisories for weeks, and your inventory will be incomplete when you start it. Start anyway.

Questions We’re Getting About PHP2Shell

Is anyone actually exploiting PHP2Shell yet?

Attempts have been recorded, though the scale isn’t clear. Amazon’s honeypot logged one on October 17, four days before the patches, and Cloudflare reported early attacks after disclosure. Early reports from other firms said they hadn’t seen any, so treat the picture as moving.

Does updating WordPress fix it?

Not by itself, because PHP is a separate layer underneath WordPress, Drupal, Joomla and Magento. A host or server admin has to update the runtime. Updating the CMS or its plugins leaves the vulnerable PHP exactly where it was.

My host says they’re handling it. Do I still need to do anything?

One thing, which is to get written confirmation that the fix is installed and not just scheduled, for every site and app you run. Hosts patch what they manage. They can’t see the forgotten staging server in your own account.

We’re stuck on PHP 7.4. What are the real options?

Your options are a vendor LTS build with the fix backported, the PHP team’s minimal source backport for 7.4, or a move to a supported 8.x release. The source backport is meant for people already building PHP themselves, so most teams end up choosing between the other two.

Realistically, how long does a PHP upgrade take?

A patch release inside the same version, like 8.3.35 to 8.3.36, can be done in about a day once you know where PHP runs. A jump from 7.4 to 8.x is a project measured in weeks, sometimes months, and in our experience the code audit decides which.

Contractor or full-time hire for this?

Bring in a contractor for the surge and hire full time for whoever owns patching afterward. Our median contract start is 3 days from an accepted offer across 1,997 starts, and a permanent IT search averages 17 days to fill.

Start With the Inventory

Before anything else, make a list of every place PHP runs in your company, and put a name next to each one. Not the team, a name. If a line on that list has no name beside it, you’ve found the thing that’s going to hurt. That’s the job.

KORE1 has been placing technical talent since 2005, and we’d honestly rather help you build the permanent patch-owner seat than keep filling emergency ones. If you’re staring at a server list with gaps in it, whether that’s a PHP migration, a compromise review or the person who should have owned all of it, talk to a recruiter. We’ll tell you straight whether the role is fillable at the number you have, and whether you need us at all. If your host already confirmed the patch, you might not.