PHP2Shell: How we protected our clients’ WordPress websites without any downtime

On 21 October 2026, one of the most serious PHP vulnerabilities in recent years came to light under the name PHP2Shell. Whilst many website operators took to social media to complain about sudden server downtime or found themselves stuck on support waiting lines for hours, the WordPress instances on our infrastructure continued to run without a hitch.

Here you can find out exactly what PHP2Shell is all about, why conventional security plugins are powerless against it, and how our tech team has already protected the websites of our clients on the server side, even before the official security updates were released.

“Huge praise to you all. Of the many hosting providers I use, you were by far the quickest to respond and apply the patch – and the platform remained accessible throughout. Some competitors are still offline…” – Feedback from a customer on the evening of 21 October

What exactly is PHP2Shell?

The name ‘PHP2Shell’ refers to two vulnerabilities in the PHP core: CVE-2026-109618 and CVE-2026-109619. The PHP Security Team’s severity rating of 9.2 (out of 10) highlights just how critical the issue is: it is a so-called pre-authentication remote code execution (pre-auth RCE).

In English, this means:

1. No login required: An attacker does not need to have a customer account or access details for the WordPress admin panel.
2. Execution of external code: Malicious code can be executed directly within the context of the web server process by means of specially crafted HTTP requests to the server.
3. Full system control as a risk: If the attack is successful, attackers can manipulate data, install backdoors or hijack server resources for malicious purposes.

Why WordPress security plugins are powerless in this situation

Many WordPress site owners rely on well-known security plugins such as Wordfence or Solid Security. However, these tools do not offer reliable protection against PHP2Shell.

A security plugin only becomes active once WordPress has already loaded and is processing PHP code. However, the vulnerability lies one level deeper – directly within the web server’s PHP runtime environment. An attack at this level often prevents WordPress from loading fully in the first place. Genuine protection against such zero-day threats is only possible at server level.

Which websites are affected?

The issue affects almost all widely used PHP branches – going back as far as older versions such as PHP 5.4. Official security releases have been made available for the actively supported versions (including PHP 8.2, 8.3 and 8.4).

The situation is particularly tricky when it comes to traditional shared hosting:

The ‘neighbourhood’ risk: if dozens of customers share the same server instance and one account is compromised via the vulnerability, the entire server is at risk.

Raidboxes architecture: We do not offer traditional shared hosting. Thanks to our container infrastructure, every single box runs in its own, mutually isolated environment without exception. Web servers, databases and caching services are strictly separated from one another. Thanks to this architecture, even in the theoretical event of a breach, it is technically impossible for the compromise to spread to neighbouring customer websites.

How we at Raidboxes dealt with PHP2Shell

The fact that our customers were able to enjoy a relaxed 21 October was down to a swift chain of response between our tech team and team.blue’s security infrastructure.

The timeline for 21 October:

• Morning – Early detection: Security researchers detect the world’s first automated waves of attacks. The BSI and CERT-EU issue the highest-level alerts. The first hosting providers shut down entire server pools as a precautionary measure; authorities and platforms worldwide switch to emergency mode.
• Morning – Preventive defence: Our tech team takes action hours before official security patches are even available. We roll out server-side filter rules and rate limits across the entire infrastructure. These block known points of entry – whilst maintaining 100 per cent uptime for all customer servers.
• 11.51 am – Transparency in customer support: The support team informs customers who make enquiries about protective measures and system stability.
• 3.30 pm – PHP brings forward the release:
  Due to massive leaks and global attacks, the official PHP team is bringing forward the release schedule and issuing emergency patches (8.2.35, 8.3.36, 8.4.27, 8.5.12).
• 4.15 pm – Fleet rollout completed: 45 minutes after the code was released, Raidboxes completes the fully automated rollout of the patches for all versions from PHP 8.2 onwards – ahead of the BSI’s final recommendations. At this point, the most severe attacks are sweeping across the global network; the attack window at Raidboxes has already been closed.

Protection even before the official patch (virtual patching)

When the warnings started coming in, there were no finished PHP updates available for download yet. If we’d waited, Raidboxes’ websites would have been unprotected for hours.

Earlier this morning, our tech team, in collaboration with team.blue’s Threat Intelligence team, made server-side configuration adjustments directly to the web server directives and network layers. These acted as a kind of digital shield: the known attack patterns were blocked before they could even reach the vulnerable routines in the PHP worker. There were no ways to bypass this protection.

Container isolation: no shared hosting, no chain reaction

One of the main reasons for global outages at large-scale hosting providers lies in outdated shared hosting structures: when hundreds of customers share the same server stack, an emergency often leads to server overload or requires a hard, collective reboot.

As each box in our system runs in separate, isolated containers for the web server, database and cache, there are no shared processes and no risks arising from insecure neighbours (‘bad neighbour effect’).

No servers had to be hard-rebooted, either for the configuration changes carried out in the morning or for the final patch roll-out at 4.15 pm. Ongoing customer sessions were completed without interruption, whilst new processes started immediately in the hardened environment.

Human support + smart live automation

Throughout the day, we received hundreds of concerned enquiries from agencies and online shop operators. Rather than fobbing customers off with standard emails, we rolled out a bilingual crisis workflow right at the height of the rush.

Routine enquiries were handled automatically, leaving our WordPress support experts free to focus on resolving complex, specialist cases personally and in depth via chat.

This meant that over 550 customers could be informed and reassured within a very short space of time.

“I was very satisfied with the support I received from raidboxes® on this matter; everything went smoothly.” — Michael Giglhuber

Why did the dashboard still temporarily show the old PHP version?

A few observant customers contacted us via live chat: “You say we’re protected – but my dashboard still shows PHP 8.3.x instead of a new version number?”

The explanation: Our preventative measure was applied at server level, prior to the actual PHP package. The protection was 100 per cent active even before the PHP binary itself was replaced. It was only after the final roll-out of the official packages that the version displayed in the dashboard changed.

Why was there no downtime at Raidboxes?

Some large-scale hosting providers were forced to take drastic measures: servers were rebooted, processes were abruptly terminated, or websites were temporarily switched to maintenance mode.

Thanks to our container architecture, we were able to implement the necessary configuration changes and the subsequent patch roll-out via a graceful reload of the processes. Existing connections were handled smoothly, and new requests were seamlessly handed over to the hardened environment – without a single second of planned downtime.

What about older versions of PHP?

In day-to-day agency work, we regularly come across client websites that cannot be updated to PHP 8.2 or 8.3 straight away due to outdated plugins. For these legacy environments, our server-side protective measures remain permanently active until the relevant backports are available.

The result: as things stand, not a single website across the entire Raidboxes infrastructure has been compromised.

Is your website not hosted with Raidboxes? Here’s how to check your setup

If you host your WordPress websites with other providers, you should take action as soon as possible:

1. Checking the PHP version in WordPress

1. Log in to your WordPress dashboard.
2. In the menu, go to Tools → Website Status.
3. Click on the ‘Report’ tab and expand the ‘Server’ section.
4. Check the entry under ‘PHP version’.

2. Check that version numbers match

The official security patches were released in the following versions:

• PHP 8.2.35 (or later)
• PHP 8.3.36 (or later)
• PHP 8.4.27 (or later)
• PHP 8.5.12 or later 

If your website is running on an older version (e.g. PHP 8.2.20 or versions below 8.2), you should urgently check with your hosting provider to see if your site is protected.

Do I need to worry when I’m just browsing the internet as normal?

No, not directly on your device. PHP2Shell attacks web servers, not the browser on your laptop or smartphone.

However, there is an indirect risk: if an unpatched website is successfully attacked, attackers can inject malicious scripts (malware, phishing forms, spam redirects) into the compromised website, which then put regular visitors at risk. Taking swift action to secure your site therefore not only protects your data, but also your customers’ trust.

What PHP2Shell reveals about the value of managed hosting 

Incidents such as PHP2Shell highlight the fundamental difference between cheap web hosting and genuine managed hosting.

Shared hosting providers sell cheap storage space. But when things go wrong, you’re left to your own devices: you have to research security alerts yourself, manually check server versions, and, in an emergency, end up dealing with support bots or overloaded helplines. If you manage 30, 50 or 100 client websites, this means nothing but stress and unpaid working hours.

Managed hosting at Raidboxes means:

• Proactive security: We take action at server level before security vulnerabilities become a problem on your website.
• No downtime: State-of-the-art container technology ensures that updates do not bring your client projects to a standstill. 
• No maintenance shifts: Our infrastructure updates itself in the background, so you don’t have to sacrifice your evenings.
• Real WordPress experts on chat: If you have any questions, you can reach people who understand WordPress within minutes, 7 days a week – no chatbots, no script-readers.

Would you like to see just how hassle-free secure WordPress hosting can be? Try Raidboxes for 14 days completely free of charge, or use our free migration service to test one of your clients’ websites in a live comparison, risk-free.