PHP Is Dead. Again. Meanwhile, Who’s Patching Your Website?

Every time PHP has a bad week, parts of LinkedIn start planning its funeral.

Somewhere between the security advisories and the framework victory laps, business owners are left wondering whether their website is about to fall apart.

If you run WordPress, WooCommerce, Laravel, Drupal, Magento or another PHP application, you deserve a useful answer.

The current vulnerabilities are serious. Your infrastructure needs attention. But choosing your next technology stack based on who is laughing loudest in the comments is an expensive way to make a business decision.

First, what actually happened?

On 21 October 2026, PHP released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, commonly called PHP2Shell. Both received a CVSS v4.0 severity score of 9.2 out of 10. Under exploitable conditions, they can let someone execute code on a server without logging in. [1][2]

In ordinary business language: an attacker could potentially make your server do things you never authorised.

The flaws are in PHP itself. Updating a WordPress plugin does not repair the engine underneath it. PHP identified all installations serving web requests as at risk, with Apache’s mod_php configuration carrying the highest assessed risk. [1]

The fixed upstream releases are:

These are the incident’s fixed releases, not a promise that they will remain the latest versions. Some hosting and operating-system vendors also backport fixes into existing packages. That means the displayed PHP version alone may not tell the whole story. [1][3]

A vulnerability is also not proof of a breach. An affected website, an attempted attack and a confirmed compromise are three different things.

If you own the business, who handles this?

On shared or managed hosting, the provider normally controls the PHP runtime and deploys its security updates. Your agency or developer usually handles the application: its CMS, plugins, themes, custom code and compatibility checks. Your actual service agreement determines the boundary.

On an unmanaged VPS, the server administrator has that infrastructure job. Paying a hosting company for a virtual machine does not automatically mean somebody is maintaining the software inside it.

Hostinger’s response makes this distinction particularly clear: it patched its managed hosting, while explicitly telling VPS customers to update their own servers. [3]

This is one reason shared and managed PHP hosting can be practical for smaller businesses. The provider spreads infrastructure operations across many customers. You do not need a dedicated operations team for every brochure site or small shop.

You do, however, need to know what your plan includes. A low hosting bill and a maintenance agreement answer different questions.

How major hosting providers responded

I work with Hostinger for hosting solutions, so I checked its response first. I also checked other providers’ published incident updates.

The table records what the providers reported, rather than an independent audit of every customer server. Checked 23 October 2026; times below are UTC.

This is the operational side of the story that a language-war screenshot usually leaves out: mitigations, packaging, rollout, verification and customer communication.

It also shows why “everyone fixed it immediately” would be too neat. Providers had different environments and rollout schedules.

Ask your host one concrete question:

Has the PHP runtime serving my website been patched for both CVE-2026-109618 and CVE-2026-109619, and are the patched processes now running?

If the version number looks unchanged, ask for the package or build confirmation. Hostinger and GoDaddy both document backported builds for this incident. A firewall rule blocking a known exploit is useful protection; the runtime patch is still necessary. [3][6]

To the JavaScript framework crowd: perhaps sit this victory lap out

I use JavaScript too. There are excellent reasons to choose React, Vue, Node.js or a full-stack JavaScript framework.

Immunity from security incidents is not one of them.

Here are documented examples from 2025 and 2026. These are different failure categories, not a league table of which language is worst.

Yes: Node.js published security fixes on the same day as PHP.

And React2Shell was not merely a theoretical embarrassment. AWS reported exploitation attempts by state-linked threat groups within hours of its public disclosure. [14]

A CVSS 10.0 score does not automatically make an incident more damaging than every 9.2 incident. Versions of the scoring system, attack conditions, exposure and the consequences for a particular business all matter.

But the evidence makes one claim difficult to defend: “This happened because PHP is old, and our modern stack has moved beyond these problems.”

We have moved beyond plenty of things. Vulnerabilities are still attending the meetings.

A technical distinction worth keeping

A runtime memory bug, a framework authorisation bypass and a stolen package-publishing account require different fixes.

You cannot solve all three by changing the language in your application files. Nor does writing application code in JavaScript remove native-code risks from the runtime and its dependencies.

React’s follow-up advisory also explicitly says its RCE patch remained effective. The subsequent denial-of-service and exposure issues required further updates for their own reasons. That detail matters if we want to criticise fairly. [12]

Why PHP’s bad week reaches so many businesses

PHP’s footprint helps explain the scale of the concern.

On 23 October 2026, W3Techs reported PHP on 69.3% of websites whose server-side language it could identify, compared with 8.2% for server-side JavaScript. [15]

Read the denominator carefully. This is not a measure of internet traffic, company revenue, all applications, or JavaScript running in browsers. A PHP website can also use React or Vue.

My inference is that this broad footprint helps explain why a PHP runtime emergency reaches so many hosting providers, agencies and business owners at once.

It does not prove that JavaScript incidents received less coverage. React2Shell clearly triggered a substantial security response. And I cannot speak for how every PHP developer behaved in somebody else’s comment section.

What I can say is that customers gain nothing when developers treat another ecosystem’s emergency as a marketing opportunity for their favourite framework.

Thirty years of history brings both experience and baggage

I still remember learning PHP from a book more than twenty years ago.

It took a long time to get from that era to today’s language and ecosystem. Decisions accumulated. Compatibility commitments accumulated. So did the number of businesses depending on them.

That history helps explain difficult engineering trade-offs. It does not excuse leaving serious risks unresolved.

The PHP Foundation acknowledges that signs of the out-of-memory problem emerged during work following a 2024 audit. Competing fixes, compatibility concerns and limited resources contributed to the delay. The Foundation explicitly describes the delay as a structural failure. [16]

That deserves scrutiny. You can support PHP while expecting better security processes.

You can also appreciate modern JavaScript without rewriting its history as “PHP, but fixed.” Different communities explored different approaches to building for the web. Businesses should choose among them based on their requirements, available expertise and the cost of maintaining the result.

AI makes the maintenance question more urgent

The PHP Foundation describes AI-assisted research and tools contributing to security work. Node.js credits OpenAI Codex Security researchers for reporting its October Brotli issue. [13][16]

That is useful progress for defenders. It also raises a practical concern: finding flaws faster only helps users if teams can validate, fix and deploy just as effectively.

A website maintenance budget may not look exciting next to an AI product launch. It still pays for work somebody has to do when the advisory arrives.

Still on PHP 7? You need a plan

W3Techs still detects PHP 7 on 26.9% of PHP websites, with PHP 5 on another 7.7%, as of 23 October. Those figures are version detections, not infection rates. [17]

PHP 8.1 and older are outside upstream support. Some vendors supply backported security fixes, including for this incident, but that is a specific support arrangement, not permission to leave an application untouched indefinitely. PHP 8.2’s security support ends on 31 December 2026. [1][18]

If your website has been frozen for years, budget for an assessment. Depending on what is underneath, the sensible route may be targeted repairs, a staged upgrade, or a rebuild.

A rebuild becomes attractive when abandoned plugins, unsupported custom code and years of workarounds make continued maintenance more expensive than replacement. A well-built application may be perfectly reasonable to upgrade.

Do the compatibility work in staging, with backups and a deployment plan. Emergency patching and long-term modernisation are related jobs with different deadlines.

And please retire the argument that a site must be secure because it still looks fine.

Malware does not have to change your homepage. Automated attacks do not need your business to be famous. Traffic and search rankings cannot tell you whether a server has been compromised.

“It still loads” is an uptime observation. It is not a security assessment.

The business owner’s ABCs

A: Assign responsibility. Know who maintains your hosting, PHP, application and third-party components. Get confirmation that this incident’s runtime patches are live.

B: Back up and prove recovery. Keep recoverable copies outside the live environment and test restores. A Git repository alone does not contain your orders, database, uploads and every setting needed to recover.

C: Keep current and keep checking. Use supported software, retire abandoned components, protect administrator accounts, monitor changes and logs, and test critical journeys after updates. WordPress’s own security guidance treats maintenance, backups and monitoring as ongoing work. [19]

The same thinking applies to your delivery tools. If a package registry or deployment service becomes unavailable, know whether you can rebuild and deploy another way. An outage and a vulnerability are different problems; both expose assumptions about who is keeping the business running.

PHP has earned criticism this week. So have the processes that allowed these flaws to linger.

What your business needs next is a named person, a verified fix and a maintained website.

Before you ask which stack is safest, ask who is responsible for keeping yours safe.

Not sure what your website runs on, who maintains it, or whether it is ready for a supported PHP version? I help businesses assess existing websites, maintain their infrastructure and plan upgrades or rebuilds around actual needs. Get in touch through DimyOsman.com.

Sources

All sources checked 23 October 2026. Hosting responses are provider-reported and scoped to the services described; they do not certify an individual website. Advisory dates and patch releases are historical; consult current advisories before applying updates.

1. PHP security release and advisory, 21 October 2026
2. CERT-EU: Critical Vulnerabilities in PHP
3. Hostinger: protections and patch rollout
4. SiteGround: critical PHP vulnerabilities response
5. Cloudways: PHP security incident timeline
6. GoDaddy: important PHP security update
7. Namecheap: PHP security incident and resolution
8. Next.js: CVE-2025-29927 advisory
9. Vercel: Next.js middleware bypass postmortem
10. debug maintainer advisory: CVE-2025-59144
11. React: critical RSC vulnerability, 3 December 2025
12. React: denial of service and source-code exposure; updated 26 January 2026
13. Node.js: 21 October 2026 security releases
14. AWS: React2Shell exploitation attempts within hours
15. W3Techs: server-side programming language usage
16. PHP Foundation: security release and process changes
17. W3Techs: PHP version usage
18. PHP: supported versions
19. WordPress: hardening and security maintenance