PHP2Shell:

what

exactly

happened?

What is PHP2Shell?

PHP2Shell is the name for two critical vulnerabilities in PHP, the programming language that a large part of the web runs on. Using specially crafted web requests, attackers could run code on a server remotely, without logging in. The vulnerabilities are registered as CVE-2026-109618 and CVE-2026-109619. Both received a severity score of 9.2 out of 10. One vulnerability involves memory corruption when the server runs out of memory. The other involves internal state that lingers after the memory it belongs to has been freed. The problem sat in PHP itself, not in a specific website or plugin. That made the impact significant. Websites and applications running on PHP, from WordPress, Joomla and Drupal to custom software, could be vulnerable. According to the Dutch National Cyber Security Centre (NCSC), every PHP installation that handles web requests was affected.

How did the disclosure unfold?

With serious vulnerabilities, details are normally only made public once a fix is available. That gives administrators the chance to update their systems before attackers can exploit the flaw.

PHP2Shell went differently. On 20 October the details leaked. Within hours, security firm watchTowr confirmed that the vulnerabilities could actually be exploited. On 21 October, Cloudflare reported the first attacks, before the security updates were even available. PHP released the updates around 14:00 UTC. In hindsight, attackers were active even earlier. Amazon recorded an exploitation attempt on 17 October. So the threat did not begin when the vulnerabilities became public.

Why was the whole industry on high alert?

PHP is a widely used foundational technology. That meant PHP2Shell did not affect one vendor or a specific group of websites, but a large part of the web. The NCSC warned that attackers could take over servers, make websites unreachable and steal data. CybelAngel counted around 2.24 million PHP servers worldwide that were directly reachable from the internet. Of the servers that reveal their PHP version, 59 percent ran a version for which no official update will be released. The severity also showed in the measures organisations took. As a precaution, the NCSC temporarily took its own website offline. Other organisations did the same. A website going offline does not automatically mean it has been hacked. Sometimes it is a deliberate measure to limit risk while a fix is being prepared.

How did we handle PHP2Shell at Cube?

We build and maintain the applications, Shock Media and Fundaments manage the servers they run on. PHP2Shell showed how well that division of roles works. We know the software and our clients, they know the infrastructure. By bringing that knowledge together, we quickly knew what each environment needed. We got to work straight away, guided by three principles:

1. Check first, then go back online.

An environment only went back online after we had checked that the security update was applied correctly. We did not just want the server to be reachable again; we wanted the necessary protection to actually be in place.

2. Careful over fast.

The update was not immediately available for every server. For some environments, it first had to be added to an open source software repository. We did not force that process. With security updates, you want to know exactly what is being installed and which version is actually running. Acting fast matters, but not at the expense of that certainty.

3. Keep checking after recovery.

Installing an update is not the end of the work. After bringing environments back online, we run additional checks to see whether they function properly and whether there are any signs of misuse. Throughout the day, we kept our clients informed about the situation and our progress. The team worked late into the evening to get the environments back online. All affected environments are now back online. The post-recovery checks are ongoing.

Why does the work not stop at back online?

A security update prevents a vulnerability from being exploited again. But it does not tell you whether an attacker had already gained access before the update. Amazon recorded an exploitation attempt as early as 17 October, four days before disclosure. That is why we do not only look at the period from 20 October onwards, but include the days before it as well. We check whether the vulnerability has been fixed and whether there are signs that anyone made use of it earlier.

Do you use PHP yourself? Here is what you can do.

Does your website or application run on PHP? Then it is important to know which version you use and whether the security update has been applied. The fixes are available in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older are no longer regularly supported. Because of the severity of the vulnerabilities, the PHP team still released minimal patches for PHP 7.4, 8.0 and 8.1. Can't update right away? Temporary mitigations are available. According to the PHP team, these only limit certain attack paths and do not fully solve the problem.

Here is what you can do:

• Check your PHP version. Ask your hosting provider or software supplier which version is running and whether the security update has been applied.

• Plan an upgrade if you run an outdated version. PHP 8.1 and older are no longer regularly supported. A minimal patch or temporary mitigation is not a structural solution.

• Have your environment checked for earlier attacks. Include the period from 17 October onwards.

• Consult the NCSC guidance. For Dutch organisations, the NCSC publishes a decision tree and tracks on GitHub which PHP-related products are vulnerable.

What does this day show?

Clients usually only notice that their website or application works. On a day like 21 October, what lies behind that becomes visible. Installing a security update is one part of it. Knowing which versions run on which servers, coordinating with the hosting partner, checking that the update was applied correctly and continuing to monitor after recovery: that is all part of maintaining software too. Many of the applications we build at Cube run on PHP. That makes vulnerabilities like this relevant to us and to the organisations we work for. We think it is important to be open about how we deal with them.