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.
Top comments (0)