Who actually owns PHP? What October’s PHP vulnerability teaches us about the engine under your website

On 20 October 2026, the PHP team warned of two critical vulnerabilities in PHP itself. A day later, on 21 October, the fix arrived. In those 24 hours, hosting providers and even the Dutch National Cyber Security Centre (NCSC) took websites offline as a precaution.

The vulnerabilities are known as CVE-2026-109618 and CVE-2026-109619, together nicknamed PHP2Shell. The PHP team rated both 9.2 out of 10 for severity. They allowed an outsider to run commands remotely on a web server, without logging in.

For most readers, this was the first time they had really heard of PHP, even though their own website has been running on it for years. This article explains what PHP is, who owns it, and why that matters to anyone with a website.

What is PHP, exactly?

PHP is a programming language that runs on the server. When a visitor opens a page, submits a form or places an order, PHP can process that request, retrieve or store data in a database, and send a response back to the browser.

You never see PHP, but it is everywhere. WordPress runs on it, as do WooCommerce, Drupal, Joomla and Laravel. According to the analytics firm W3Techs, around 69 per cent of all websites whose server-side language is known run on PHP.

Think of it as the electrical wiring in a building. Visitors see the interior: your design, your copy, your forms. Nobody gives the wiring a second thought – until there’s a short circuit.

Who owns PHP?

Nobody owns PHP in the way that Oracle owns Java. There is no company that owns the language, and no company you can ring when something goes wrong.

Formally, the copyright on PHP rests with The PHP Group, a small group of early core developers. The copyright on PHP’s technical engine, the Zend Engine, belongs to Zend, which is now part of the software company Perforce. PHP is open source: anyone may use, inspect and improve it free of charge.

The language is developed by a community of volunteers and paid developers. They vote on new features through a public proposal process known as RFCs (Requests for Comments). Anyone who wishes can follow how each decision is made.

Since late 2021 there has also been The PHP Foundation. This non-profit pays developers to work on PHP itself. It was set up on the initiative of JetBrains, together with Automattic (the company behind WordPress.com), Laravel, Symfony and Zend, among others. The foundation is funded by companies and individuals, but it doesn’t own the language either.

Zend once played a major role in PHP’s development. Today, however, the company has no say over the language: the community decides what goes into it.

In short, one of the most important building blocks of the internet is maintained by a relatively small group of people, funded by voluntary contributions.

Why an up-to-date WordPress site wasn’t enough

This vulnerability wasn’t in a plugin or in WordPress, but one layer deeper. So a website that was fully up to date could still be vulnerable.

A website consists of layers that rest on top of one another:

1. Theme and plugins: what you see and use, such as forms and sliders.
2. The CMS, for example WordPress.
3. PHP: the language the CMS runs on.
4. The server: the operating system and software that keep everything running.

WordPress’s automatic updates only cover the top two layers. PHP and the server are updated by whoever manages the hosting. WordPress.org and WooCommerce accordingly stated that no update was needed on their side: the fix had to come from the PHP layer.

A security plugin didn’t help much here either. Such a plugin is itself PHP code and only kicks in after PHP has already processed the request. Firewalls such as Cloudflare’s blocked known attack attempts, but Cloudflare, too, advised updating PHP itself.

What we can learn from this

Open source works, but it doesn’t work by itself. The PHP team released a fix for millions of websites within a day, without anyone paying a licence fee for it. That is impressive.

At the same time, this week showed how fragile that dependency is. According to The PHP Foundation, the first signs of the problem were already visible in 2024, and the fix was released a day earlier than planned because details had leaked. The foundation itself pointed out that its security team now receives far more reports than it used to, thanks to AI-assisted research. More work, then, for the same small group of people.

Three lessons for anyone with a website:

• What’s underneath matters as much as what’s on the surface. A polished, up-to-date site on an outdated PHP version is an open door.
• Versions expire. Each PHP version receives security updates for a few years. PHP 8.1 and older no longer receive any, and support for PHP 8.2 ends on 31 December 2026.
• Someone has to be responsible. With a vulnerability like this, every hour counts. It needs to be clear in advance who updates the PHP layer, how quickly, and who then checks that everything still works.

What can you do now?

The fix is included in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your website runs on an older version, or you don’t know, ask your hosting or maintenance provider these three questions:

1. Which PHP version is my website running on now, and does it include the fix for CVE-2026-109618 and CVE-2026-109619?
2. Were the PHP processes restarted after the update?
3. Who will keep the PHP layer up to date from now on, and how quickly does that happen when a critical vulnerability appears?

Ask for the answers by email, so you have them to hand next time. If your website was online during the vulnerable period, also have it checked for any unknown administrators, files or plugins that may have been added.

What we did last week

On 21 October, just before 4pm, the fix became available. At that point, our team got to work together with our network partner Nextpertise. We updated DirectAdmin, the control panel for our servers, and rolled out the patched PHP versions.

By 7pm, all our servers were running PHP 8.2.35 or later. Within three hours of the release, every website we host was protected.