Is PHP Dead? A 2026 Reckoning

“PHP is dead” is a claim older than the iPhone. It was wrong in 2008, wrong in 2015, wrong in 2020, and it remains wrong in 2026 but not for the reasons the PHP community likes to argue. PHP is not dead; PHP is boring, and boring is exactly what a language that runs 70%+ of the web is supposed to be. This article separates the four claims people actually mean when they say “PHP is dead” market share, language design, security posture, and talent pipeline examines each against current data, and argues that the interesting question is not whether PHP is dying but what kind of language it has become.

1. What people actually mean

When someone says “PHP is dead,” they are usually making one of four distinct claims, and conflating them is why the debate never resolves:

1. Market share claim. PHP is losing the web to Node, Python, Go, or whatever the current favorite is. Shared of new deployments is falling, and eventually PHP will be a legacy language like COBOL.
2. Design claim. The language is fundamentally broken inconsistent standard library, weak type system, historical baggage and modern alternatives are strictly better for new code.
3. Security claim. PHP is the language of choice for insecure code, LFI, RCE, and webshells, and it cannot be made safe.
4. Talent claim. Nobody wants to write PHP anymore, so the ecosystem will rot from the bottom as senior engineers leave.

Each of these deserves a separate answer. None of them, individually, is “yes, PHP is dead.”

2. Market share: the boring numbers

2.1 The web is still PHP’s territory

As of late 2025 / early 2026, W3Techs reports roughly:

• ~72–75% of all websites whose server-side language is known are running PHP.
• ~55% of the top 1,000 sites run PHP the number falls with site rank, not rises, which is the opposite of a language in decline.
• WordPress alone is ~43% of the web, and WordPress is PHP. So is Joomla, Drupal, Magento, PrestaShop, MediaWiki (Wikipedia), and a large fraction of long-tail SaaS.

The “market share is falling” argument is true in the narrow sense that PHP’s share of new projects has declined from ~80% in 2010 to where it is now. It is false in the operational sense: the sites that exist are still PHP, they are still maintained, and they are not migrating. Rewriting 43% of the web in Rust is not a project anyone is going to undertake.

2.2 What “decline” actually looks like

A language in decline has a recognizable signature:

• New frameworks stop appearing.
• The language’s runtime stops getting new releases.
• Hosting providers stop offering it.
• Security advisories stop being issued (because nobody’s looking).
• The community’s flagship conferences shrink.

PHP in 2026:

• New frameworks keep appearing — Laravel still ships annually, Symfony is on a two-year LTS cadence, and there is active work on FrankenPHP, Swoole, RoadRunner as non-FPM runtimes.
• The runtime gets an annual major release — PHP 8.4 shipped in November 2024, PHP 8.5 is in the 2026 cycle. RFCs continue at a healthy rate.
• Hosting is trivial — every shared host, every VPS provider, every container base image has PHP.
• Security advisories are issued and patched at a rate comparable to any other actively maintained runtime.
• Conferences — PHP Community, Laracon, SymfonyLive, PHPUK draw the same crowds they have for a decade.

None of that is a language in decline. It is a language that has stopped growing and started consolidating. Consolidation is what happens to a language that has won its category.

2.3 The comparison that matters

Category	Dominant language	Age	Status
Server-side web	PHP	1995	Consolidated
Systems	C	1972	Consolidated
Data / science	Python	1991	Growing then consolidating
Mobile	Swift / Kotlin	2014 / 2011	Growing
Frontend	JS/TS	1995/2012	Consolidated

Consolidation is not death. C has been “dying” for 30 years while running the kernel, most of the cloud, and every embedded device on the planet. PHP is in that category for the web. The interesting question is not “is PHP dying” but “what is PHP’s permanent role.”

The permanent role is: the language of the long-tail web. The CMS, the e-commerce stack, the internal tool, the agency project, the site that needs to exist in six weeks and be maintainable by whoever comes next. That role is not going away.

3. Design: the language got better while you weren’t looking

3.1 What PHP 5 looked like

The “PHP is bad” critique is largely a critique of PHP 4 and early PHP 5 a language that had:

• No namespaces.
• No real OOP (PHP 4 “objects” were arrays with syntax sugar).
• mysql_query with no prepared statements.
• register_globals on by default.
• magic_quotes a failed escape-everything approach to SQLi.
• Inconsistent standard library (str_replace vs strstr vs strpos, mysql_ vs mysqli_ vs PDO).
• preg_replace with /e doing code execution on the replacement string.

Every one of those critiques was valid. Every one of them is gone.

3.2 What PHP 8.x actually is

PHP 8.4 (Nov 2024) and 8.5 (in the 2026 cycle) are a different language from the one people are critiquing:

• Namespaces (5.3, 2009).
• Real classes, traits, interfaces, enums (enums in 8.1).
• Strict types per-file (declare(strict_types=1)).
• Typed properties, typed parameters, typed returns (7.0–8.0).
• Union types, intersection types, never, mixed (8.0–8.2).
• Readonly properties, readonly classes (8.1–8.2).
• First-class callable syntax ($fn = strlen(...)).
• Constructor property promotion.
• Match expressions (a proper replacement for switch).
• Named arguments.
• Fibers (8.1) the cooperative concurrency primitive under Swoole, ReactPHP, Amp.
• JIT (8.0) the runtime is not a bottleneck for typical web workloads, and the JIT helps for CPU-bound ones.
• Property hooks (8.4).
• Asymmetric visibility (8.4).
• Deprecation of dynamic properties (8.2), mysql_* (5.5), ereg (5.3), etc.

If you write PHP 8.4 with declare(strict_types=1), constructor promotion, enums, readonly, and match expressions, you are writing a language that looks a lot like TypeScript with a runtime that’s actually better at servers.

3.3 The real critique that survives

There are legitimate design critiques of PHP 8 in 2026:

• Naming inconsistency in the standard library persists. str_contains and str_starts_with exist, but so do strstr, stristr, strrchr, strpbrk, strspn. You have to know the history.
• The function namespace is global every extension dumps functions into the root namespace. This is why you get array_map and spl_autoload_register at the same level.
• Error handling is a mixed bag. PHP 8 unified exceptions heavily, but E_WARNING-level failures still exist and behavior varies.
• The type system is nominal and not gradual-complete. strict_types helps, but the language doesn’t have full soundness and mixed is a real type.
• The standard library is not the standard library. strlen is core, but mb_strlen is in mbstring, which is optional. json_encode is core, but curl is an extension, and pdo_mysql is an extension. The runtime ships with a base and a lot of optional parts.

These are real. None of them is a reason to rewrite a working application in another language.

3.4 The comparison that matters, again

PHP’s critics compare PHP to Rust, Go, and TypeScript. That comparison is almost always the wrong one. PHP is comparable to:

• Ruby on Rails same era, same “rapid web development” niche, same consolidation trajectory. Rails is not dead; neither is PHP.
• Python web (Django/Flask) same niche, same era, same “the language got better” trajectory.
• Java Enterprise same “boring and everywhere” trajectory.

Against those, PHP 8.4 is doing fine. Against Rust, PHP is not trying to compete, and neither is Rust trying to compete with PHP.

4. Security: PHP is not the problem, and 109618 proves it

This is the most interesting angle in 2026, because the two CVEs we discussed last week — 109618 and 109619 — are engine-level bugs, not application-level ones.

4.1 The old story

For most of PHP’s history, “PHP is insecure” was a fair critique of the application layer:

• register_globals + no input validation → variable injection.
• mysql_query("SELECT * FROM users WHERE id=$_GET[id]") → SQL injection.
• include($_GET['page']) → LFI/RCE.
• eval($_POST['code']) → webshells.
• assert($_GET['code']) → same.

These were real. They were also beginner mistakes that the language made easy, not vulnerabilities in PHP itself. The community’s response was correct: deprecate and remove the primitives that make these mistakes easy, and let frameworks and IDEs handle the rest.

4.2 The modern story

By PHP 8.4:

• register_globals — removed in 5.4 (2012).
• magic_quotes — removed in 5.4 (2012).
• mysql_* — removed in 7.0 (2015).
• preg_replace /e — removed in 7.0 (2015).
• create_function — removed in 8.0 (2020).
• assert() string eval — removed in 8.0 (2020).
• $$ variable variable — deprecated, still a footgun.
• include from remote URL — allow_url_include off by default.

The application layer footguns are gone or off by default. What remains is:

• Deserialization — unserialize is still a footgun; use json_decode instead. Frameworks handle this.
• File inclusion — still possible if the application does it; allow_url_include=Off is the default.
• Function injection via callbacks — array_map('system', $arr) is still a thing; not a language bug, a code-review bug.

None of these is “PHP is insecure.” They are “a programmer who reads untrusted data wrong will have a bad time in any language.”

4.3 What 109618 and 109619 mean

The two CVEs we covered last week are engine-level memory corruption and use-after-free bugs in the Zend allocator and request-shutdown path. They are:

• Not PHP-specific. Every C runtime has had OOM-unwind bugs (glibc, jemalloc, OpenSSL’s allocator, every V8 release). Every long-lived server has had request-recycle UAFs (Node, Ruby, Python).
• Patched promptly. The fixes shipped in minor releases, as usual.
• Not a “PHP is insecure” data point — they’re a “software is written by humans” data point, and the same class of bug exists in every comparable runtime.

The interesting 2026 security story is not “PHP is insecure.” It’s “the security community has finally stopped treating PHP as the problem and started treating the code running on it as the problem” which is what the community has been saying for fifteen years, and what the rest of the industry is now catching up to.

4.4 The actual PHP security posture in 2026

• CVSS-scored CVEs in the PHP runtime are in the same order of magnitude per year as Python, Ruby, and Node. No language is safe from its own memory management.
• Application-layer CVEs in WordPress plugins outnumber runtime CVEs by 50–100×. Those are plugin author bugs, not PHP bugs.
• The framework ecosystem Laravel, Symfony, Drupal, Magento has mature security-advisory processes and fast patch cadences.
• The hardening path disable_functions, open_basedir, noexec on /tmp, egress filtering is well documented and widely deployed.

PHP is not the most secure runtime in the world. It is also not the least. It is somewhere in the middle, which is where most mature runtimes sit.

5. Talent: the pipeline is not what you think

5.1 The claim

“Nobody wants to write PHP anymore, so the ecosystem will rot as seniors leave and juniors don’t arrive.”

5.2 The counter-evidence

• Laravel and Symfony job postings remain steady. Not growing fast, not collapsing.
• The PHP subreddit, Laracasts, Laravel Daily, SymfonyCasts continue to produce content and attract new people.
• PHP is taught in CS curricula in exactly the same proportion it was ten years ago — which is to say: a little, usually badly, and the people who want to write it learn it on the job.
• The senior PHP community is stable. The people who maintain Composer, PHPUnit, PHPStan, Psalm, the frameworks, and the extensions have been at it for 10–15 years and are not leaving.

The “talent cliff” argument conflates the language being fashionable with the language having practitioners. PHP is not fashionable and has practitioners in the millions. Rust is fashionable and has practitioners in the hundreds of thousands. Both are fine, and the talent pool for PHP is not going to disappear in the next decade.

5.3 The real talent issue

The real issue is that PHP’s talent is concentrated in maintenance, not greenfield. People who know PHP well are maintaining WordPress, Drupal, Magento, and legacy Laravel applications. They are not building the next React Native app. That’s fine for PHP the applications still need to be maintained but it means the language’s public perception is dominated by maintenance work, which is unglamorous, which feeds the “dead” narrative.

The narrative will keep being wrong as long as the maintenance work needs doing. And the maintenance work is going to need doing for at least another two decades.

6. What “PHP is dead” actually sounds like from inside

If you spend a week in a PHP shop in 2026, this is what you hear:

“We’re migrating off PHP to Node.” → They are migrating one service off PHP. The monolith is staying.

“Nobody writes PHP anymore.” → The person saying this has a Laravel side project.

“We should rewrite in [language of the year].” → The rewrite is 18 months in and still not shipped.

“PHP 8 is actually fine.” → Said reluctantly, by someone who hasn’t written PHP since 5.6 and just read the release notes.

The pattern is consistent: people who work in PHP professionally do not think it’s dead. People who don’t work in PHP think it is. The latter group is the one that writes the blog posts.

7. What PHP becomes

If PHP is not dying, what is it becoming? The trajectory I see is:

7.1 The boring, correct answer

PHP becomes the COBOL of the web. Not because it’s old and musty, but because:

• It runs a huge fraction of the world’s web infrastructure.
• It will keep running it for decades.
• New projects will increasingly choose other languages, and that’s fine.
• The PHP that remains will be maintained, patched, and depended upon, invisibly.

This is not a bad fate. C is the COBOL of systems programming, and it runs the kernel, the cloud, and every embedded device on the planet. “COBOL of the web” is a compliment, not an insult it means the language occupies a load-bearing niche that nobody can afford to rip out.

7.2 The framework answer

The PHP that survives is increasingly frameworks, not the language. Laravel is its own language at this point. Symfony is its own language. The people who write “PHP” in 2026 mostly write Laravel or Symfony, and the framework absorbs the language’s inconsistencies and exposes a coherent surface. That is why PHP 8’s improvements are felt unevenly: the people on the framework don’t see them; the people on the language do.

7.3 The runtime answer

PHP is bifurcating into two runtimes:

• Classic FPM — the request-per-worker model. This is what 99% of PHP deployments are, and will continue to be. Boring, correct, well-understood.
• Long-lived — FrankenPHP, RoadRunner, Swoole, ReactPHP, Amp. These treat PHP as a server language rather than a scripting language, which brings it closer to Node and Go in how it thinks about concurrency. This is where new PHP engineering attention is going.

The bifurcation is why the language feels unsettled. Nobody’s sure which model the next decade belongs to. Both will survive; the balance between them is what changes.

7.4 The AI answer

A surprising amount of AI-assisted coding in 2026 is generating PHP, because:

• The training data is enormous (WordPress, Laravel, Symfony codebases dominate GitHub’s PHP corpus).
• The patterns are well-known enough that LLMs get them right.
• The language is forgiving of “close enough” code.

This is not a “PHP is dead” data point, but it’s a shift: PHP is becoming the language that AI writes well, which is a real form of consolidation. People will keep using PHP because AI tools make them productive in it, not in spite of it.

8. The verdict

PHP is not dead. PHP is consolidated.

Consolidation is what happens to a language that has won its category and settled into maintenance. It is the same place C is in, the same place Java is in, and the same place Ruby is in. Languages in this state have:

• Massive existing codebases.
• Stable, well-funded maintenance.
• Declining new-project share.
• No plausible extinction event.

The “PHP is dead” narrative is a new-project narrative. It is true that new projects are less likely to choose PHP than they were in 2010. It is false that this means PHP is going away. The people who write it professionally are not leaving; the codebases are not migrating; the runtimes are not being abandoned; the patches keep coming.

If you want a useful posture toward PHP in 2026:

• If you’re building new: choose based on team, ecosystem, and operational context. PHP is a reasonable choice if the team knows it and the ecosystem (WordPress, Laravel, Magento) fits. It is not the right choice for systems programming, ML, or anything where a different language has a specific advantage.
• If you’re maintaining: learn PHP 8.x properly. declare(strict_types=1), typed properties, enums, readonly, match, first-class callables. The language is better than the version you learned in 2014.
• If you’re debating it: stop. The debate is settled. PHP is boring and everywhere, and that’s not going to change.

The next time someone tells you PHP is dead, ask them which of the four claims in §1 they’re actually making. Nine times out of ten, they’ll realize they don’t know.

9. Epilogue: the CVE-2026-109618/109619 connection

Last week’s article on 109618 and 109619 was, in a sense, a companion piece to this one. The bugs are real, engine-level, and patched. What the article could not say, and what this article can, is that:

• The bugs are not evidence that PHP is insecure. They are evidence that PHP is maintained bugs of this class are found and patched precisely because people are still looking.
• The fact that we can write a 5,000-word article about the OOM unwind and the worker-recycle path is a sign of a healthy engine, not a dying one. A dead language has no one reading the source.
• The chain trigger, shape, land, PHP2Shell is a demonstration that PHP is still interesting enough to warrant deep technical work. That is not what happens to a language that’s been abandoned.

PHP is not dead. It’s the boring foundation the web stands on, and the fact that its foundations are still being audited is the surest sign it isn’t going anywhere.