Is PHP Dead? What the 2026 Hack Changes

Is PHP dead? No, and the October 2026 vulnerabilities do not change that. They do show which PHP sites are in trouble: the ones running versions that no longer receive security fixes. According to W3Techs, PHP is used by 69.3% of websites with a known server-side language, and the project has an 8.6.0 release candidate in testing. The question worth asking is not whether PHP survives, but whether your PHP site is on a version that does.

This is part 3 of The Web After PHP2Shell. Part 1, PHP vulnerability 2026, covers the flaws and fixes, and Part 2, AI security vulnerabilities, covers how AI sped them up. Here we look at the bigger question people are searching for after a week like this one, with sourced data, and finish with a decision table for stay, upgrade or rebuild.

On this page

• Is PHP dead? What the numbers say
• What did the 2026 flaws actually prove?
• Why were so many PHP sites exposed?
• What will replace PHP?
• Is PHP still a good choice for a new project?
• Stay, upgrade or rebuild?
• Where PHP goes after PHP2Shell

Is PHP dead? What the numbers say

Three sourced facts answer the question as asked.

Usage. W3Techs reports PHP on 69.3% of websites whose server-side language is known, as of 23 October 2026. A separate W3Techs page shows WordPress on 39.6% of all websites and 58.3% of sites with a known CMS on the same date. WordPress is written in PHP, so a large share of PHP’s footprint is WordPress’s footprint.

Development. The php.net supported versions page lists PHP 8.5, released on 20 November 2025, among the currently supported branches, and the PHP news feed shows 8.6.0 RC4 released for testing on 21 October 2026. A dead language does not ship release candidates.

Maintenance. The project fixed the 2026 flaws in all four supported branches on the day of disclosure, and its security team also published source backports for three unsupported ones. That is not abandonment.

What the numbers do not show is a trend. We looked for a trend we could verify and found only single-day snapshots, so we make no claim that PHP’s share is rising or falling.

Scroll the diagram sideways to see all of it.

What did the 2026 flaws actually prove?

They proved that a widely deployed runtime can have serious, long-lived bugs, and that attackers now move quickly on them. They did not prove that PHP is a uniquely bad language.

Both CVEs are classed as use-after-free faults (CWE-416) in the GitHub advisories. A use-after-free is a memory safety error in the interpreter, the engine underneath your code. It is not something a PHP developer writes into an application. In December 2023 CISA published guidance on memory safe roadmaps recommending that software makers move toward memory safe languages to eliminate this class of vulnerability. That is a multi-year engineering goal for runtimes in general, not a verdict on one language.

The right comparison is not “PHP versus the rest” but “what else has happened to mainstream server-side stacks”. In December 2025 the React team disclosed CVE-2025-55182, scored CVSS 10.0, a flaw in how React decodes request payloads that allowed unauthenticated code execution on servers running React Server Components. It affected Next.js and other frameworks. It was a different class of bug, in a different layer, in a different ecosystem. It had the same consequence.

Scroll the diagram sideways to see all of it.

Why were so many PHP sites exposed?

Because of how PHP is deployed, not how it is designed. Four operational facts explain most of the exposure.

1. Old versions are common. W3Techs shows 34.7% of PHP sites on PHP 7 or older, and some of the 65.3% on “PHP 8” are on 8.0 or 8.1, which are also out of support. Those branches received no official release for this fix.
2. Fixes need action by someone else. On shared and managed hosting, the host installs the fixed build and restarts PHP. Owners wait. This is why Part 1 tells you to ask your host in writing.
3. Plugin updates do not help. A WordPress or Drupal update changes the application. These bugs were in the engine underneath, so a perfectly updated site on an old PHP was still exposed.
4. mod_php carries the highest risk. PHP says a demonstrated exploit can trigger the attack before any application code runs on Apache with mod_php.

None of that is unique to PHP in principle. Any popular runtime with millions of unattended installs would show the same long tail. PHP’s long history and low barrier to hosting simply produced more of them.

What will replace PHP?

Nothing is replacing it in the near term, and the likely drift is slow. LogRocket’s 2026 trends article, published in December 2025, expects meta-frameworks such as Next.js and Nuxt to become the default starting point, typed server functions to replace many separate backends, and more code to run at the edge. It also expects the security problems of that ecosystem, including React2Shell, to push frameworks toward safer defaults. That describes where new JavaScript projects are going. It does not describe existing PHP sites migrating.

For most businesses the realistic choices are:

• Stay on PHP, on a supported version, with managed patching.
• Keep the CMS but publish static pages, so the public site does not run PHP on each request. Part 4, static vs dynamic website, covers this.
• Rebuild on another stack, which is a project with its own costs and its own advisories to follow.

Even Teamvoy, which sells application modernisation, advises patching or isolating this week and modernising only where an inventory shows apps stuck on unsupported versions. Read that as a vendor’s view, but it matches the evidence.

Is PHP still a good choice for a new project?

It can be, but the right question is about operations as much as language. For a new site, ask who will patch it, how fast, and how much of it needs to run code at all.

• Who patches the runtime? A managed platform that updates PHP for you removes most of the risk this week exposed. A server you administer yourself puts that job on your team, every time.
• How much of the site is dynamic? A marketing site with a blog and a contact form needs very little server code. A store with accounts needs a lot. The less code runs per request, the less a runtime flaw can reach.
• What does your team already know? A competent team on a supported PHP stack usually beats a rushed move to an unfamiliar one. Rewrites introduce their own bugs.
• What is the exit cost? Whatever you choose, keep content in portable formats and keep your build reproducible, so that changing course later is a project and not a crisis.

None of this is an argument against PHP. It is an argument for choosing a stack you can keep current, and for sending less traffic through code you do not need. Ambeltek’s own site is built on Astro, which publishes pre-built pages instead of running an application server for every visit, but we recommend dynamic stacks where a project genuinely needs them.

Stay, upgrade or rebuild?

Decide by version and by what the site does, not by the headline.

Scroll the diagram sideways to see all of it.

If you do rebuild, treat it as a migration with search risk, not a reskin. Keep URLs, redirect what changes and test before launch, using the website migration SEO checklist. The web development process guide shows what a sensible build timeline looks like, and how much does a website cost gives realistic budget ranges.

Where PHP goes after PHP2Shell

PHP will most likely come out of this week the way mature infrastructure usually does: patched, scrutinised and still everywhere. Expect more attention on the engine, more pressure on hosts to patch faster, and more sites quietly retiring PHP versions they should have retired years ago. The language is not the thing to worry about. The unpatched copy of it on your server is.

If you are weighing a rebuild, Ambeltek’s web development service can tell you honestly whether your site needs one or just needs a supported PHP version and a patch routine. The next article, static vs dynamic website, looks at the middle option, and Part 6 covers the future of web development more broadly. For the WordPress-specific angle, see WordPress SEO.