On October 21, the PHP project released an emergency security update for two critical vulnerabilities in PHP itself. Together, they have become known as PHP2Shell.
PHP is the language behind WordPress, Drupal, Joomla, Magento and many of the web’s most widely used content management systems. If you run a website, there is a good chance it relies on PHP, even if you have never had to think about it.
That is what made PHP2Shell different from the usual plugin or application vulnerability. The flaw was not in one website, one CMS or one piece of software. It was in the layer underneath all of them.
Here is what PHP2Shell is, why the hours immediately after a security fix is released are often the most dangerous, and what happened on our servers.
What PHP2Shell is
PHP2Shell refers to two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, in the core PHP runtime. Both are rated 9.2 out of 10 in severity.
The first involves the way PHP behaves when it runs out of memory. Under the right conditions, an attacker can send a specially crafted request that leaves PHP in a partially initialized state and potentially allows the attacker to execute their own code on the server.
The second involves the way PHP cleans up memory between requests. Data from one request can survive into the next, potentially allowing an attacker to read information belonging to other visitors or, in some cases, execute code.
The memory disclosure is particularly serious. Researchers demonstrated that information such as passwords, session tokens and API keys from other requests being processed on the same server could potentially be exposed, without the attacker ever logging in.
In practical terms, a single crafted web request sent to an unpatched server could potentially give an attacker control of a website or access to sensitive information belonging to other visitors.
The vulnerable code had been present in PHP for more than a decade, meaning nearly every PHP version released since 2012 was affected. The researchers who discovered the vulnerabilities, at Wiz, Calif and OpenAI, have also said that AI tools helped them turn the underlying flaws into working exploits far faster than would traditionally have been possible.
Why updating your website does not fix it
Most website security advice eventually comes down to one rule: keep your software updated.
That advice is still correct. It just does not solve PHP2Shell.
Updating WordPress, your theme or your plugins does nothing to fix these vulnerabilities because the problem is not in any of them. It is in the PHP runtime the server uses to execute them.
A website can be perfectly maintained and completely up to date and still be vulnerable if the PHP underneath it has not been patched.
Only the server operator can install that fix. For most website owners, that means their hosting provider.
And that raises a more important question than simply whether your host patches security vulnerabilities:
How quickly do they patch them?
The race between the patch and the exploit
A security patch does two things.
It fixes the vulnerability, but it also shows attackers where the vulnerability was.
Once a patch is published, anyone can compare the old code with the new code and see exactly what changed. For a vulnerability this serious, that comparison becomes a roadmap for developing an exploit.
Researchers and attackers increasingly use the same AI-assisted tools to analyze those changes. As a result, the time between a patch becoming public and a working exploit appearing has compressed dramatically.
We wrote in May about how quickly a published security fix can now be turned into a working exploit. PHP2Shell is one of the clearest examples we have seen.
The vulnerabilities were originally scheduled to be disclosed on October 22. On October 20, information about them leaked publicly, prompting the PHP project to move the release forward by a day. A video showing a working exploit was briefly posted online before the official fix had even been released.
By the afternoon of October 21, security firms were already reporting exploitation attempts against servers on the public internet.
Within days, the U.S. Cybersecurity and Infrastructure Security Agency added both vulnerabilities to its catalogue of flaws known to be actively exploited.
Some organizations chose to take services offline rather than remain exposed. BambooHR, the HR and payroll platform, temporarily shut down services in Canada, the United States and Ireland. Several Dutch government services did the same.
Every hour a server remained unpatched after October 21 was another hour it was exposed to attacks that were already circulating.
That is the window that matters.
Not simply whether your host eventually installs the patch, but how long it takes them to do it.
What happened on our servers
We knew the fix was coming.
The PHP project had published an advance notice the previous evening, so we had already prepared the rollout and were monitoring for the updated packages to become available.
When they appeared on the morning of October 21, we began installing them within minutes.
We first deployed the update to a single server and verified that everything was operating normally. From there, we rolled it out across every server we operate in a controlled sequence.
On each server, PHP was updated and restarted, the installed version was verified, and websites were spot-checked afterwards.
The rollout covered every PHP version in use on our network, including older versions that are no longer officially supported by the PHP project. Those releases did not receive official PHP updates, but patched builds containing backported fixes were made available, and we installed those as well.
Our clients did not need to do anything.
There was no maintenance window to schedule, no email asking customers to update their websites, and no downtime associated with the rollout. We also did not see any customer sites break as a result of the update.
By the time much of the industry was still reading about PHP2Shell, our servers were already running the patched versions.
That is what managed hosting is supposed to mean.
The server is our responsibility. When a serious vulnerability appears in server software, fixing it is our job – without waiting for a monthly maintenance cycle and without waiting for a customer to ask.
What to ask your host
If your website is hosted somewhere else, there are a few questions worth asking.
Has PHP2Shell been patched on the server running my website, and when was it patched?
The answer should include a specific date, ideally October 21 or October 22. If the answer is vague, or the provider cannot tell you, that is useful information in itself.
Do you install critical server security updates as soon as they are available, or do you wait for a scheduled maintenance window?
A fixed monthly maintenance schedule made more sense when attackers sometimes needed weeks to turn a published vulnerability into a practical exploit. That is no longer a safe assumption.
What version of PHP is my website using, and is that version still receiving security updates?
Many websites are still running PHP versions that have been unsupported for years. In the case of PHP2Shell, those versions required a backported fix that not every hosting provider will necessarily have installed.
You can check your PHP version in cPanel under MultiPHP Manager, or in WordPress under Tools → Site Health.
If your site is running PHP 8.2 or newer, the patched releases are:
- PHP 8.2.35
- PHP 8.3.36
- PHP 8.4.27
- PHP 8.5.12
If your site is running anything older than PHP 8.2, ask your hosting provider directly whether a backported PHP2Shell fix has been installed.
The bottom line
PHP2Shell was a vulnerability in the foundation underneath a huge portion of the web.
There was nothing a typical website owner could do inside WordPress, Drupal, Joomla or another CMS to close it. The fix had to happen at the server level.
That makes the speed of your hosting provider’s response especially important.
The period between a security patch becoming available and that patch being installed is increasingly the most dangerous part of a vulnerability’s lifecycle. With PHP2Shell, attackers were already probing internet-facing servers the same afternoon the fix was released.
Whether your host eventually patches a critical vulnerability matters.
How long they leave you exposed before doing it matters more.
A disclosure, since this is a hosting provider’s blog: we are CanSpace, a Canadian-incorporated hosting company with Canadian data centres and Canadian-staffed support.
Patching PHP2Shell within minutes of the fixed packages becoming available was not a special response for us. It is how we handle critical security updates across the servers we manage, on every plan.
If you want hosting where server patching is handled for you, our web hosting plans, VPS and dedicated servers are fully managed.
And if you are not sure whether your current host has patched PHP2Shell, send us a note. We can tell you what to check.
