Radar

PHP2Shell: What the critical PHP vulnerability means for your website

October 22, 2026 · 6 min read

On 21 October 2026, PHP patched two critical vulnerabilities that affect almost every WordPress, Shopware or JTL site. Who is affected, how hosting providers responded, and what you should check now.

Read article

The short answer

On 21 October 2026, the PHP project closed two critical security vulnerabilities, known together as PHP2Shell. They let attackers run arbitrary code on a web server without logging in. Practically every website running on PHP is affected: WordPress, WooCommerce, Shopware, JTL and many more.

The only thing that protects you is a PHP update on the server. Updating WordPress or your plugins does not help. On regular shared hosting, your provider installs the update. We spent 21 and 22 October working through this with our clients, checking in with hosting providers and taking some sites offline as a precaution. Here is what happened and what you should check now. Status: 22 October 2026.

What is PHP2Shell?

PHP is the programming language behind a large share of all websites. Every time someone opens your site or submits a form, PHP processes that request on the server.

PHP2Shell is the collective name for two bugs in that core, tracked as CVE-2026-109618 and CVE-2026-109619. The PHP security team rates both 9.2 out of 10, the highest severity level.

Put simply, this is what happens. If PHP runs out of memory in the middle of processing a request, it aborts, but during cleanup it still treats the half-finished data as valid. The second bug is a close relative: leftovers from one request stay in memory, and a later request accesses them even though they are long invalid. Both are triggered by crafted form and upload requests, and they fire before your website's code even starts. Your site can be cleanly built and still be vulnerable.

Why this is so serious

Normally this kind of thing happens quietly. Researchers report the flaw confidentially, PHP builds a fix, and details are published only with the update. This time the information leaked early on 20 October, and PHP moved the release forward by a day. So attackers knew early. Cloudflare and watchTowr reported exploitation attempts, some before the update was out; as of the evening of 21 October, no successful break-ins had been publicly documented.

If an attack succeeds, the attacker can do anything on the server your website can do. They read access credentials, reach the database with customer and order data, plant a backdoor or send spam from your domain. Being a small business does not help, because these attacks are automated. Bots scan the entire internet for vulnerable servers, and whether a corporation or a local trade business sits behind one is something they never check.

Who is affected?

Anyone whose website runs on PHP and has not been updated yet. Only these versions are safe:

PHP 8.5 from 8.5.12
PHP 8.4 from 8.4.27
PHP 8.3 from 8.3.36
PHP 8.2 from 8.2.35
PHP 8.1 and older: no official update

So it is not just old installations. Current versions are vulnerable too until the update is installed. Anyone still on PHP 8.1 or older gets no fix from the PHP project and has to move to a current version.

Systems without PHP are not affected, such as Shopify, Webflow or static sites, for example built with Astro.

Two cards: sites running PHP need an update, sites without PHP are not affected — PHP sites need the server update. Shopify, Webflow and Astro do not.

How the hosting providers responded

On regular shared hosting you depend on your provider. We work with several, and the differences on 21 October were striking.

The fastest, in our experience, was Raidboxes. WordPress sites hosted there were secured within a very short time, and Raidboxes confirmed to other agencies on 21 October that PHP 8.2 to 8.5 had been patched. JTL proactively informed its customers by email; according to JTL, all hosted shops were quickly moved to patched versions, and for us the hole was closed after around 30 minutes.

All-inkl preventively disabled a PHP feature for upload progress indicators on all servers, which according to what was known at the time is one of the attack paths. At the same time, the customer panel, webmail and web FTP were offline. We found no announcement on their own website; the information mostly circulated through customers in forums. IONOS reported security maintenance on its status page with completion within 24 hours, Alfahosting also communicated via its status page and was still working on the updates on 21 October.

For us as a creative studio, that often made it impossible to tell for sure whether a given client site had been secured. At many providers, the information available was thin.

What we did

If we cannot say for certain that a server is patched, we assume the worst. So we temporarily took a number of client sites and some of our own projects offline. Instead of the website, the server delivered a simple maintenance page in plain HTML, which runs without PHP and cannot be attacked.

That included sites where you would not expect it. Plain HTML sites with a contact form, for example: the site itself is static, but the form sends its data through a small PHP script, and that script is a possible entry point. Similar with Webflow. Webflow itself does not use PHP and is not affected, but for our clients we often add our own PHP-based mail delivery so that form data does not end up with Webflow in the US but stays under the client's control. Good for data protection, but on this day a reason to lock the PHP part until the patch. That also applied to the site of our consulting firm Cozmoo.

Our own website stayed online. We recently moved it from Webflow to Astro with Sanity, hosted on Cloudflare, and it runs entirely without PHP. Why we took that step is explained in a separate article: Webflow or Astro with Sanity. Security was not the main reason, but it paid off that day.

What you should do now

If you are on regular shared hosting, your provider installs the update. Three things still fall to you:

Check which PHP version your website uses. In WordPress it is under Tools → Site Health → Info → Server.
If you are still on PHP 8.1 or older, switch to 8.3 or 8.4 in your provider's customer panel and then test the homepage, forms and checkout.
Ask your provider whether the fix for CVE-2026-109618 and CVE-2026-109619 is installed on your server. The version number alone proves little, because some providers apply fixes without changing it.

If you run your own server, you have to update yourself and restart all PHP processes. Until then, offline is the better choice.

The patch only closes the door, and whatever got in before stays. So check whether new admin accounts or unknown PHP files have appeared since 20 October, especially in upload folders. For a shop with customer data, we recommend changing all passwords as a precaution.

What will not help you: security plugins, the maintenance mode in WordPress or Shopware, and theme or plugin updates. All of that runs only after PHP has already processed the malicious request.

Not sure whether your website is secured?

We look after websites and shops on WordPress, Shopware, JTL, Webflow and Astro. During PHP2Shell we checked the status at the hosting providers for our clients, locked sites as a precaution and released them again after the update. If you do not know whether your site is affected, or need help moving to a current PHP version, get in touch for a no-obligation first call. We will take a look.