PHP2Shell explained: what it means for your website.

Last updated: 21 Oct 2026. I'm updating this note as new details are confirmed.

On 21 October 2026 the PHP project shipped emergency fixes for two critical vulnerabilities in PHP itself. Security researchers have named the pair PHP2Shell. If your website runs on WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel or anything else built in PHP, this one applies to you, and it's not something a plugin update will sort out.

This note covers what the flaws are in plain terms, which versions are safe, and what to do this week. I've kept the technical detail to what a business owner or marketing lead needs to make a decision.

What PHP2Shell is

PHP is the language your web server uses to run most websites. When someone visits a WordPress page, PHP on the server builds that page. PHP2Shell is two separate bugs in the way PHP handles memory while it processes a web request:

• CVE-2026-109618. If PHP runs out of memory at the wrong moment while setting up a request, some internal data is left half-built. PHP's clean-up step then treats it as valid, which an attacker can use to run code.
• CVE-2026-109619. Some data from one request can survive after its memory has been freed. A later request handled by the same PHP worker can then pick up that stale data, which can leak memory contents or lead to code execution.

Both are rated 9.2 out of 10 on the CVSS v4.0 scale. What makes them serious is that the attacker doesn't need a login, and the flaws don't depend on your website's own code. The flaws were reported by three research teams: Calif, Wiz Research and OpenAI's Codex Security. Wiz demonstrated taking control of default installs of WordPress, Drupal and Joomla using nothing but crafted web requests. They also noted that even a bare "Hello World" PHP page on an affected version can be vulnerable.

Why this one is different

Most website security news is about a single plugin or theme. You update the plugin and move on. PHP2Shell sits a layer below that, in the runtime every PHP site depends on. That has two consequences.

First, updating WordPress, your theme or your plugins does nothing for this. They don't control which PHP version your server runs. The fix happens on the server, either by your host or by whoever manages it.

Second, the reach is enormous. W3Techs puts PHP behind about 7 in 10 websites whose server-side language it can identify, and researchers report that affected versions go back to PHP 5.4, released over a decade ago. According to the PHP project, every installation serving web requests is at risk, whether it runs through PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed.

The disclosure also went badly. Details leaked online on 20 October, before the fixes were out, and PHP was reported to have brought its release forward by a day. By the time patches shipped, Cloudflare said it was seeing early attacks and watchTowr reported exploitation attempts against both flaws. The US agency CISA said on 21 October that it had not yet observed exploitation, and neither flaw was on its Known Exploited Vulnerabilities list at that point. CISA urged organisations to patch immediately, and the UK's National Cyber Security Centre advised updating quickly and isolating anything that couldn't be fixed. Reports like these tend to firm up quickly once the details are out, so I'm treating the risk as live.

Is my website affected? Which versions are fixed

One thing that trips people up: Linux distributions such as Ubuntu, Debian and Red Hat often backport security fixes into their own packages without changing the headline version number. A server showing "PHP 8.1.2" might be patched if it's on a supported distribution release. The reliable check there is the package changelog, looking for the two CVE numbers, not the version string.

How to fix PHP2Shell: what to do this week

1. Find out your PHP version. In WordPress, it's under Tools, Site Health, Info, Server. In cPanel, look for MultiPHP Manager or Select PHP Version. I've written a step-by-step guide to checking your PHP version for every common setup.

2. If you're on shared or managed hosting, ask your host directly. Many hosts patch PHP centrally, and some had patches ready on release day. But hosting panels usually let each site pick its own PHP version, and a site still set to 7.4 or 8.1 may not get the fix even if the host patched everything else. Ask for a yes or no on your specific account and version.

3. If you run your own server, update now and restart PHP. Install the fixed release for your branch, then restart every PHP worker (PHP-FPM, Apache or LiteSpeed). A patched binary that hasn't been restarted is still running the old code.

4. If you're on 8.1 or older, plan the upgrade. This is where most of the real work sits. Moving from 7.4 to 8.3 is a big jump. Old themes, page builders and abandoned plugins often break, and checkout or payment plugins need careful testing on an online store. Do it on a staging copy first, with a full backup, rather than flipping the version on a live store and hoping.

5. Use stopgaps only as stopgaps. PHP's advisory lists interim settings for servers that can't be patched straight away, For CVE-2026-109619 that means turning off session.upload_progress.enabled and restarting PHP. For CVE-2026-109618 it means tightening memory and request-size limits. These block the confirmed attack paths, not every variant. The PHP team is clear that updating is the only complete fix. Some web application firewalls, including Cloudflare's, have added rules for PHP2Shell, which buys time but doesn't replace the patch.

6. If you take a site offline to patch, serve a 503. Google's guidance for planned downtime is to return HTTP 503 (service unavailable), not let pages time out or throw 404 and 500 errors. A short 503 window won't hurt your rankings. A day of errors can.

7. Check you weren't hit before the patch. I've listed ten signs your website has been hacked, with what to do if you find one. Look for admin users you don't recognise, unfamiliar PHP files in upload folders, new scheduled tasks and recently changed core files. Researchers have also flagged unusual multipart form uploads followed by "allowed memory size exhausted" errors, bursts of PHP worker crashes and restarts, and PHP processes launching shells or download tools such as curl as signs worth investigating. If a site was exposed before it was patched, change its passwords, API keys and payment gateway keys. The memory-disclosure side of these bugs can leak them.

If the fix is on your host's side, your job is to get a clear answer from them, not to assume.

South African sites

MyBroadband found more than 9,800 South African servers running PHP in a Shodan search the day before the patch, including on Afrihost and xneelo networks. When I checked on 21 October, I couldn't find a public PHP2Shell statement from Afrihost, xneelo or Domains.co.za, or an alert from a South African government CSIRT. That doesn't mean they haven't patched. It means you should ask, in writing, about your specific account.

Here's an email you can send your host as is:

What this costs if you ignore it

Remote code execution means an attacker can do anything your web server can do. On a typical small business site that includes reading the database (customer details, orders, enquiry forms), adding spam pages that damage your search rankings, injecting card-skimming code into a checkout, or using your server to attack others. Your host may suspend the account if it starts sending spam or malware, which takes the site offline until it's cleaned.

For a business that relies on its website for leads or sales, the clean-up is the expensive part. Restoring from a clean backup, finding how the attacker got in, rotating every password and key, and requesting a review from Google if the site got flagged all take far longer than a planned PHP upgrade.

Where I can help

I'm a web developer first. I've worked on hundreds of websites across many hosting platforms and content management systems, including WordPress, WooCommerce and Joomla, and keeping them secure has always been part of the job. Patching PHP and moving live sites between PHP versions without breaking checkout is routine work for me. If you'd rather not work through the steps above yourself, send me your web address through the free PHP2Shell website check. I'll tell you whether you're exposed, whether your host has already patched you, and what the fix involves, with a fixed quote before any work starts. If you're already safe, I'll tell you that too.

If it's urgent, WhatsApp or email me and I'll reply within one working day: rob@chiefgrowthengineer.com or +27 66 212 7955.

Filed under: Security · PHP · WordPress · 2026

Sources: PHP project, PHP Foundation, CISA, NCSC, MyBroadband, Tenable, php2shell.com, Armis, Wiz Research, Huntress, watchTowr, Google Cloud, The Hacker News. Details were still developing at the time of writing.