PHP2Shell explained: what happened with the PHP vulnerability
On Wednesday 21 October 2026, an urgent security update for PHP was released. It fixed two serious vulnerabilities that quickly became known as PHP2Shell. Dutch government websites such as DigiD (the Dutch government login service) and Overheid.nl, as well as several hosting companies, went offline that day as a precaution. In this article we explain what was going on, even if technology is not your thing. And we tell you honestly what we did.
Do you have a website with Theory7? Then you do not need to do anything yourself. We installed the updates on all our web hosting servers and checked each server individually. We did not have to take a single website offline as a precaution. If you want to check for yourself, this article (in Dutch) explains how.
PHP2Shell in brief
- What: two serious vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, together called PHP2Shell.
- Severity: 9.2 on a scale of 10. An attacker could take over a web server without a password.
- Who: almost every website that runs on PHP. That is roughly 70 percent of the web.
- Fix: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, released on 21 October 2026.
- At Theory7: known attack route closed on Wednesday morning, all servers updated during the night of 21 to 22 October.
What is PHP, actually?
A website has two sides. The front is what you see in your browser: text, photos, buttons. The back runs on a server and makes sure the front shows the right thing at the right moment. When you fill in a contact form, log in to an online shop or add something to your shopping cart, the back takes care of it.
Compare it to a restaurant. The dining room is what the guest sees. The kitchen is where the work happens. PHP is the language in which that kitchen is set up for a great many websites.
And that is no exaggeration. According to the research firm W3Techs, around 70 percent of all websites whose technology is known run on PHP. WordPress is built in PHP, as are WooCommerce, Joomla, Drupal and Magento, plus countless online shops, booking systems and customer portals. A flaw in PHP itself is therefore not a flaw in one website. It is a flaw in the foundation beneath a large part of the internet.
What exactly is PHP2Shell?
Researchers found two flaws in the way PHP handles a server's working memory. While it works, a server keeps all kinds of things in that memory. If something goes wrong during a request, PHP is supposed to clean everything up neatly. In certain situations, that did not happen properly.
You can compare it to a hotel that rents out a room again while the previous guest still has a key card that works. Anyone who knows how to use that card gets into a place where they have no business being. With PHP2Shell, an attacker could use this to make the server carry out their own commands.
Three things made PHP2Shell so serious:
- No password was needed. An attacker could try it from the outside, with an ordinary request to a website.
- The attacker gained control. The technical term is remote code execution: the server does what the attacker tells it to.
- It was in PHP itself. Not in a plugin or theme, but in the foundation. Almost all PHP versions since 2012 were vulnerable.
Both vulnerabilities received a severity score of 9.2 on a scale of 10. The official descriptions are in PHP's security advisories for CVE-2026-109618 and CVE-2026-109619.
How could this happen?
PHP has been around since 1995 and is maintained by a large group of volunteers and companies. Code on that scale always contains bugs. That is true of all software. These two were hidden in a corner you rarely run into: the moment a server runs out of memory in the middle of a request. Exceptions like that are hard to test, which is why the flaws went unnoticed for years.
Normally, fixing a vulnerability like this happens quietly. Researchers report it to the developers, who build a fix, and on an agreed day the update and the explanation are published together. That gives administrators a head start on attackers. The researchers found these vulnerabilities in August and reported them to PHP. The update was scheduled for Thursday 22 October.
Things went differently. On Tuesday 20 October, the first details leaked online. PHP therefore brought the update forward by a day, to Wednesday afternoon. According to security company Sansec, Cloudflare saw the first attack attempts on Wednesday morning, before the update was even available. Amazon even reports an attempt on 17 October, four days before the announcement.
That made for an unusual Wednesday in the Netherlands. DigiD, MijnOverheid and Overheid.nl, key online services of the Dutch government, were temporarily taken offline as a precaution. Several hosting companies also took their customers' websites offline while waiting for the update.
What does AI have to do with PHP2Shell?
AI played a role on both sides of this story.
In finding it. The researchers who found PHP2Shell worked with AI models from companies including OpenAI and Google. Google writes that its Gemini model made a major contribution, from finding the vulnerability to checking the fix. AI can read through huge amounts of code in a short time and spot patterns that people overlook. That is good news: old, hidden flaws come to light faster.
On the other side. The same technology is also available to people with bad intentions. Turning a description of a vulnerability into a working attack used to take days or weeks of research. With AI, that goes much faster. As a result, the time between "a vulnerability is known" and "the first attacks" keeps getting shorter. With PHP2Shell it was less than a day.
For a hosting company, that means installing an update "sometime this week" is no longer good enough. You need to know in advance exactly what is running on which server, and be able to act immediately once the update is out. We use automation and AI for this ourselves, for example to check all our servers at the same time so that no forgotten PHP version is left behind anywhere. Every change to a server was only made after approval from one of our system administrators.
What did we do about PHP2Shell?
With us, you choose which PHP version your website uses, from older versions to the newest. That means many different PHP versions run side by side on our servers, and all of them had to be updated.
We made the most important decision on Wednesday morning. The attack worked through a known entry point: a part of PHP that hardly any website uses. We switched that part off on all our web hosting servers and managed servers, before the update was even available. That allowed us to keep websites online instead of taking them offline as a precaution. We also updated all PHP versions to the newest available version in advance, so that the real update could be installed faster afterwards.
| When | What happened |
|---|---|
| August 2026 | Researchers find the vulnerabilities, partly with the help of AI, and report them to PHP. |
| Tuesday 20 October | Details leak and PHP brings the update forward. We map all PHP versions on all our servers, including our internal systems. |
| Wednesday 21 October, morning | We close the known entry point for the attack on all our servers. Cloudflare sees the first attack attempts. |
| Wednesday 21 October, during the day | Government websites and several hosting companies go offline as a precaution. We do not need to take any websites offline. |
| Wednesday 21 October, 15:38 | PHP releases the update. Within the hour, our first server is updated. |
| Wednesday evening | The default PHP on all our servers runs the new version. CloudLinux delivers updated builds, including for older PHP versions. |
| Night to Thursday 22 October | All PHP versions on all our web hosting servers are updated. |
| Thursday 22 October, morning | Final check of all servers and internal systems: nothing missed. |
The PHP versions you choose for your website come from CloudLinux, the operating system on our servers. CloudLinux also makes fixes for older PHP versions that PHP itself no longer updates. After the update, we checked on each server that the fix was really in place, and tested websites before and after.
What could PHP2Shell have done?
Suppose a server had not been updated in time. What could an attacker then do with a website?
- Steal data. A website's database often contains names, addresses, orders and login details of customers.
- Intercept payments. Code can be secretly planted in an online shop to capture visitors' payment details, without the owner noticing anything.
- Read out secrets. Passwords and keys can leak through the server's memory, for example those for the connection with your payment provider or accounting software.
- Misuse your website. For fake login pages, spam or redirecting visitors to scam sites. The result: Google warns visitors that your site may have been hacked, and your email ends up on blacklists.
You might think: my website is too small to be interesting. Unfortunately, that is not how it works. Attackers do not search for victims by hand. They let programs scan the entire internet for vulnerable websites, within hours of an announcement like this. Every website with a vulnerable PHP version is then a target, big or small.
And the damage is not just technical. If personal data leaks, you as a business owner have to report it to the Autoriteit Persoonsgegevens, the Dutch data protection authority. On top of that come recovery costs, lost revenue and a dent in your customers' trust.
At Theory7, every website runs in its own isolated environment. If something does go wrong somewhere, a break-in on one website does not simply spread to its neighbours. That is an extra layer of security, but no substitute for updating on time.
Do you need to do anything after PHP2Shell?
Not for the PHP update itself. We do have a few tips:
- Check it if you like. Our knowledge base article (in Dutch) explains how to see that the update is installed, and why your version number sometimes stays the same.
- Are you using PHP 8.1 or older? This time a fix was also released for those versions, but that is not always the case. Switch to PHP 8.2 or higher. This article explains how to choose the right version.
- Keep your website itself up to date. We take care of the server and PHP. You update WordPress, plugins and themes yourself. You will find more tips in website security: 8 tips against hackers.
- Do you have a website elsewhere or your own server? Then check whether PHP has been updated to version 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or newer.
You can always find the latest status of outages and maintenance at status.theory7.net. Not sure about your own website? Create a ticket with your domain name. We are happy to check it for you.
Software vulnerabilities will keep appearing, even in the foundation of the internet. What counts is how quickly they are fixed. That kept us busy this week, and that is how we will keep doing it.
Frequently asked questions
What is PHP2Shell?
PHP2Shell is the nickname for two serious vulnerabilities in PHP (CVE-2026-109618 and CVE-2026-109619), announced on 21 October 2026. An attacker could use them to take over a web server without a password. PHP fixed them in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
Was my website at Theory7 vulnerable?
In principle, every website running on PHP was vulnerable until the update. On Wednesday morning, 21 October, we had already closed a known entry point for the attack, and we then installed the updates on all our web hosting servers, the last ones during the night of 21 to 22 October.
Why did other websites go offline while Theory7's did not?
Anyone who could not safely wait for the update took websites offline as a precaution. We had already closed the known entry point for the attack on Wednesday morning, before the update was available. That meant websites with us could stay online while we installed the update.
Do I need to do anything myself?
Not for the PHP update, we installed that. If you use PHP 8.1 or older, we recommend switching to PHP 8.2 or higher. Also keep your website itself up to date, such as WordPress and plugins.
How do I check whether my PHP has been updated?
Look at the build date of your PHP version. If it says 21 October 2026 or later, the update is included. Our knowledge base article on the PHP security update (in Dutch) explains step by step how to check this.
