DEV Community: Kwame Oteng Appiah-Nti

In Defense of PHP: A Language That Runs the Web Doesn't Get to Die from Bad PR

Kwame Oteng Appiah-Nti — Sat, 24 Oct 2026 07:11:41 +0000

Another October, another existential crisis for PHP. The PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) dropped with a CVSS score of 9.2, a botched disclosure timeline, and a media cycle that practically wrote PHP's obituary for it. As a PHP veteran, I've watched this movie before. But this time, the script is different. The real story isn't about a language flaw; it's about a culture of not understanding your own code and a convenient amnesia about where the actual breaches are happening.

The Leak Was the Story, Not the Language

Let's be precise about what happened. The PHP Foundation ran a coordinated disclosure process for two critical RCE bugs. The fixes were ready. Patches were released for PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21, 2026. The Foundation acknowledged a "structural failure": the flaw was first spotted in 2024, but the security team, constrained by consensus and resources, stalled on a fix. That is a governance and funding problem, not a language design flaw.

Then the embargo broke. A consultant leaked the CVE IDs. A security firm published a proof-of-concept video. Chainguard shipped patched container images more than six hours before the official release, letting attackers study the fix in binary form while everyone else was still waiting. The Foundation itself called out this unilateral move.

What followed was predictable: millions of exploit attempts, mass website takedowns across European governments, and headlines that treated PHP as the culprit. But the culprit was a broken disclosure ecosystem, not the fact that PHP exists. Every piece of software of this scale and age has vulnerabilities. The question is how they are handled, and in this case, the handling failed despite the language, not because of it.

The Real "Code You Don't Understand" Problem: Vibe Coding

If you want to find the actual security crisis in 2026, look at vibe coding. The entire premise of the "vibe coding" movement is that you can generate code with AI and not read it afterward, just ship it. The research is damning.

A Georgia Tech study scanned 43,000 security advisories and found 74 confirmed cases of AI-introduced vulnerabilities, including 14 critical ones: command injection, authentication bypass, server-side request forgery.
A benchmark of 186 real-world tasks found that while 57% of AI-generated solutions were functionally correct, only 11.8% were secure.
Vibe-coded applications exhibit "placeholder logic, unfiltered input, and secret exposure", systematic failures that stem from AI agents' memory loss, locally optimized objectives, and insufficient security knowledge.
One analysis found 2.74 times more security issues per pull request in AI-generated code compared to human-authored code, and a 100% failure rate on basic CSRF protection across tested production applications.

This is what happens when you deploy code you don't understand. PHP is not the problem. The problem is a generation of developers being told that comprehension is optional. A language is a tool; if you don't know how to use it, or what the AI generated with it, the vulnerability is in the operator, not the tool.

The Cloud Isn't Safe Either: Big Tech's Own House Is on Fire

The narrative that PHP is uniquely dangerous collapses when you look at the infrastructure hosting the "modern" stack. In April 2026, Vercel, the platform behind Next.js and a darling of the JavaScript ecosystem, suffered a major breach. The attack vector? An employee at a third-party AI vendor (Context.ai) was infected with Lumma Stealer malware, harvested credentials, and used stolen OAuth tokens to pivot into Vercel's internal systems and exfiltrate environment variables.

Vercel's CEO described the attacker as "highly sophisticated" and "significantly accelerated by AI". The breach didn't come from a PHP flaw. It came from the identity supply chain of the cloud-native world: OAuth tokens, third-party SaaS vendors, and broad "allow all" permissions.

Big Tech spent a decade marketing the cloud as the secure, scalable alternative to "legacy" self-hosting. The message was: trust our infrastructure, and you'll be safe. But the Vercel breach shows that the cloud simply moves the attack surface: from your code to your OAuth grants, from your server to your vendor's laptop. AWS environments, Google Workspace tokens, and CI/CD pipelines are now the new perimeter. PHP running on a bare-metal server you actually control is not the weak link in that chain.

Modern PHP Is a Performance Beast (If You Bother to Look)

The "PHP is slow" meme is a decade out of date. The ecosystem has quietly undergone a renaissance:

FrankenPHP bundles PHP into a single Go binary with an embedded Caddy webserver and runs in worker mode, delivering 5 to 15x the requests-per-second of traditional PHP-FPM on the same hardware. Symfony benchmarks show 2x to 4x more RPS with median latency divided by three.
RoadRunner is a Go-based application server that keeps PHP workers warm, offering a plugin ecosystem for gRPC, queues, and KV storage: 9,200 RPS with 3ms latency in Symfony benchmarks.
Mago is emerging as a high-performance alternative to PHPStan for static analysis, and the tooling around type safety and code quality is maturing rapidly.

I've run PHP side-by-side with Rust and Go in production. The idea that PHP cannot hold its own is a myth propagated by people who haven't benchmarked a modern runtime. The language's core (English-like syntax, shared-nothing request isolation, and an enormous standard library) makes it uniquely suited for the web. The JIT compiler in PHP 8+ and the worker-mode runtimes have closed the performance gap that once justified migration to other stacks.

The Quiet Proof: A Solo Framework With Zero CVEs

I am Kwame Oteng Appiah-Nti. I have been working on WebbyPHP since 2020, a lightweight, modular, "lego-like" PHP framework extended from CodeIgniter 3 that I built for my own personal projects. It is not a corporate-backed mega-framework. It does not have a foundation, a security team, or a marketing budget. It is just code I wrote, understand, and maintain.

Recently, I was checking on SEO rankings and I chanced WebbyPHP showing in Aikido Intel, the same security intelligence feed that tracks over 167,000 vulnerabilities and 118,000 malware entries across open-source ecosystems. I opened it and obviously it had run some analysis on it long ago. The result stopped me.

Aikido found zero vulnerabilities in both webbyphp/webby and webbyphp/engine. No CVEs. No malicious packages. Nothing.

What it did flag were maintenance warnings, the kind that come from a one-person project: quiet commit activity, a small user base, and no automated security scanning configured in the repository. Those are fair critiques of a solo maintainer's bandwidth, and I accept them. But they are hygiene warnings, not security failures.

Then I looked at the frameworks that dominate the headlines, the ones with full-time teams, corporate sponsors, and massive adoption.

The results are below:

webbyphp/webby as seen on aikido intel

webbyphp/engine as seen on aikido intel

Laravel, the flagship of modern PHP, has had its GitHub packages compromised by a credential stealer, with Aikido Security itself reporting the incident. The Laravel-Lang supply chain attack saw 233 manipulated version tags across four Composer packages, with malicious code executing automatically through Composer's autoloader. Laravel's own TokenGuard has suffered authentication bypass vulnerabilities allowing unauthenticated attackers to authenticate as other users.

Symfony, the enterprise standard, has accumulated a steady stream of CVEs: parser recursion issues, denial-of-service vectors, and security control bypasses across multiple release branches.

WordPress, which powers over 43% of the web, required emergency patches for an unauthenticated RCE in its core, wp2shell, confirmed as SQL injection, affecting releases 6.9.0 through 7.0.1.

CodeIgniter, the very lineage WebbyPHP extends, has its own CVE trail: header validation failures, denial-of-service in the Language class, information leakage, and arbitrary code execution through validation placeholders.

These are not obscure packages. These are the pillars of the PHP ecosystem. And Aikido's own analysis shows they carry CVEs, while a solo developer's personal framework, built and understood line by line, carries none.

This is not an indictment of Laravel or Symfony or WordPress. They are massive, complex systems with enormous attack surfaces, and their teams work hard to patch what they find. The point is simpler and more uncomfortable: a framework's size, budget, and popularity are not proxies for its security. A small codebase that its author actually understands, with a narrow surface and no sprawling dependency tree, can be more secure than a monolith maintained by a committee.

That is the irony at the heart of the PHP2Shell panic. The narrative says PHP is broken, and the big frameworks are the "serious" option. The data says the big frameworks are the ones with the CVE histories, and the quiet, hand-built, understood code is the one that passed clean.

If you don't understand your code, no framework and no AI will save you. If you do understand it, even a one-person project from Accra can stand next to the giants and come out with a clean sheet.

PHP Powers the Web. It Will Continue to Power the Web.

Here is the number that matters: 69.3% of websites with a known server-side language use PHP, according to W3Techs data from October 22, 2026, after the vulnerability panic. Earlier 2026 data put the figure at 72.4%, and even the most conservative estimates place PHP above 70%, more than Node.js, Python, and Go combined.

WordPress alone powers over 43% of the web, and it runs on PHP. Drupal, Joomla, MediaWiki, Nextcloud, Laravel, Symfony: the list of PHP-powered systems is the actual backbone of the internet.

This dominance is not an accident of history. It is the result of a language that solved the web's core problem (handling HTTP requests, managing state, and rendering dynamic content) with a simplicity and ubiquity that no other stack has matched. PHP's shared-nothing architecture means a bug in one request doesn't poison the next. Its English-like syntax lowers the barrier to entry, which is why it became the language of the open web rather than the language of a single corporation's walled garden.

The PHP2Shell saga is a security governance failure, not a language failure. The vibe coding crisis is a comprehension failure, not a PHP failure. The Vercel breach is a cloud supply-chain failure, not a PHP failure.

PHP has survived the "PHP is dead" meme for fifteen years. It survived the jump to PHP 7 and the JIT revolution of PHP 8. It will survive this. The language runs the web because it is the web, and no amount of bad-faith panic-posting changes the fact that 69% of the internet's server-side logic is written in it. If you don't understand your code, the problem isn't the language. If you don't understand your infrastructure, the problem isn't the server. PHP will continue to dominate the World Wide Web, and the people who actually build things with it will keep shipping.

Why do some developers compare PHP and NodeJS?

Kwame Oteng Appiah-Nti — Thu, 27 Aug 2026 02:15:58 +0000

Why do developers compare PHP and Node.js? (Spoiler: One is a language, the other is a magician’s hat)

And why most people don’t actually know what a programming language is.

Let’s set the scene. You are in a job interview, or perhaps a Reddit thread, and someone asks, “Which is better for the backend? PHP or NodeJS?”

You brace yourself for the usual fanboy war—talk of performance, syntax, and frameworks. But if you stop and think about it, this question is linguistically nonsensical. It’s like asking, “Which is better for breakfast? Eggs or the oven?”

Yet, this comparison happens every single day. The reason isn't stupidity; it’s a fundamental misunderstanding of what makes a programming language a language.

Here is the hard truth: NodeJS is not a programming language. PHP is.

The Vocabulary vs. The Stage

Let’s get the definitions straight.

PHP (Hypertext Preprocessor) is a programming language. It has its own syntax, rules, and vocabulary. You write code in PHP to tell the computer what to do.

NodeJS is a runtime environment. It is essentially a "magician's hat" that allows you to run JavaScript on a server. If NodeJS isn't a language, what is it running? JavaScript.

So, when developers compare PHP and NodeJS, they are actually comparing PHP to JavaScript (the languages), but they are bundling it with the execution environment (Node) to judge server-side capability.

Why the Confusion Exists

Why do we forgive this technically incorrect comparison? Because, in practice, they serve the same function: Server-side execution.

For a long time, if you wanted to write dynamic websites, your only reliable option was to write PHP, slap it on an Apache server, and hope for the best. Then, in 2009, Ryan Dahl created NodeJS, allowing developers to use the client-side language (JavaScript) to talk to a server.

Because they occupy the same "space" (backend web development), developers began using the names of the ecosystems interchangeably. They don't say "I'm building this in JavaScript"; they say "I'm building this in Node." And they don't say "I'm building this in the PHP runtime"; they just say "PHP."

The Core Misunderstanding: What is a Language?

The reason this comparison persists comes down to a crucial gap in knowledge: many developers don't understand the difference between syntax and execution.

A Programming Language is the syntax. It is the grammar and vocabulary. It dictates how you write if/else statements, how you define variables, and how you structure data.
A Runtime is the engine. It is the thing that reads that grammar and executes it on your machine.

When you say "PHP is slower than Node", you are making a category error. You are comparing the speed of PHP's engine (Zend Engine) to the speed of JavaScript's engine (V8). You are not comparing the languages themselves; you are comparing their "cars."

The "Language" vs. "Tool" Distinction

To put it in perspective:

PHP is a hammer. It is a tool you use to build things.
NodeJS is a workbench. It is a stable platform upon which you place your tools (JavaScript).

You wouldn't say, "Which is better for building a chair? The hammer or the workbench?" You would say, "Which is better for building a chair? The hammer or the saw?" (Saw being JavaScript).

In the same way, the debate should be: PHP vs. JavaScript. Not PHP vs. Node.

Why does this matter beyond semantics?

If you are going to be a developer, understanding the architecture of your tools is essential.

Troubleshooting: If you think NodeJS is a language, you will look for language-level bugs. In reality, Node is a C++ program that executes JavaScript. If you have a memory leak, knowing it's the V8 engine (the runtime) rather than your JavaScript syntax is crucial for fixing it.
Learning Curve: If you think NodeJS is a language, you might try to learn "Node" without learning JavaScript. You will fail. Node doesn't have its own syntax; it only provides libraries (like fs and http). You must learn the base language first.
Ecosystem Growth: PHP is evolving the language itself (adding attributes, enums, etc.). Node is evolving the environment (adding better TLS, HTTP/2 support). Knowing which is which helps you follow the right roadmap.

The Evolution of the "Comparison"

Historically, this comparison made slightly more sense in the PHP 5.x days.

Back then, "PHP" meant the language, the runtime, and the framework all rolled into one messy amalgamation. But in the modern era, PHP is a language that runs on the PHP runtime (Zend). Node is a runtime that runs the JavaScript language on the V8 engine.

They are completely different species that have converged to occupy the same ecological niche (servers).

Conclusion

So, why do developers compare PHP and NodeJS? Because we are lazy linguists. We use shorthand to describe our "stack" rather than our "code."

When a developer says "I prefer Node," they are actually saying "I prefer the JavaScript language, as executed by the V8 engine via the Node runtime, for server-side logic." That is a mouthful.

The next time you see this debate online, don't get angry at the person for making the comparison. Use it as a teaching moment. They aren't wrong to compare the ecosystems; they are just mistaken about the vocabulary.

Remember: You code in PHP. You code in JavaScript. You run them on the PHP runtime and NodeJS. If you can keep those categories straight, you are already ahead of the curve.

What’s your take? Do you prefer the strict syntax of PHP or the event-driven flexibility of JavaScript? Let me know in the comments (and feel free to correct me on my categories!).

Nice one

Kwame Oteng Appiah-Nti — Tue, 11 Aug 2026 22:38:08 +0000

Jun Han

Apr 19

OpenClaw is old? Run Hermes Agent in VS Code through ACP (Agent Client Protocol) now!

#agents #ai #vscode #typescript

2 min read