PHP2Shell: what PHP's emergency release means for your site

Published 21 Oct 2026

Graphic for the post PHP emergency release: what it means for your site. PHP 8.5: update to 8.5.12. PHP 8.4: update to 8.4.27. PHP 8.3: update to 8.3.36. PHP 8.2: update to 8.2.35. PHP 8.1 and older: upgrade to a supported version.

Wondering about your PHP version? Run the free PHP2Shell check — instant, no email.

PHP is the language WordPress runs on, so when the PHP security team says "critical" and gives the world a day's warning, it's worth five minutes of your time. On 20 October 2026 php.net posted an advance notice of a security release for Wednesday 21 October at 14:00 UTC (16:00 South African time). The release is out now. Here's what it means for your site, and why the version of PHP you're on matters more than usual this time. The two bugs now go by the nickname PHP2Shell.

Short version:

  • Two critical holes, both rated CVSS v4.0 9.2, are fixed in this release. That's php.net's own rating.
  • The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
  • On PHP 8.1 or older? There's no official update. php.net put out bare-bones patches for 7.4, 8.0 and 8.1, and some vendors backport fixes, but upgrading is the real fix.
  • On 8.2 or newer? Your host has to install the update. Most good hosts do it quickly, but check rather than assume. Here's what the big hosts have said.

Update, 24 October: attacks vs actual hacks

There's been a lot of scanning and exploit attempts since the 21 October release, including traffic tied to a Mirai botnet variant called Potassium. SecurityWeek's round-up on 23 October (Sophos, Hunt.io, Wordfence, SOCRadar) still has no confirmed compromise in the wild, and CISA's 23 October update says the same. Sansec had walked back its early "mass exploitation" call, saying public exploits failed on default PHP setups. That picture changed on 25 October — see the update below. Qualys, cited in that same SecurityWeek piece, puts about 71% of PHP installs on end-of-life versions that will never get an official patch.

So the job hasn't changed. Get onto a fixed build (8.2.35, 8.3.36, 8.4.27 or 8.5.12), or ask your host whether yours already has the 21 October fixes. On 8.1 or older, the real fix is moving to a supported PHP version.

One more CVE landed on 23 October, CVE-2026-115560. There's no patch yet. It only hits unusual setups that flip session.serialize_handler at runtime with session upload progress still on. Normal WordPress doesn't do that, and the session.upload_progress.enabled=0 setting from the PHP2Shell advice already covers it.

Not sure what your server reports? Run the free PHP2Shell check, or jump to what to do today.

Update, 25 October: after the patch

If your site starts throwing 500 errors or blank pages right after your host applied the PHP2Shell update, check the memory limit before you assume the worst. The patched builds (8.5.12 and 8.4.27) add a hard memory ceiling. In some cases a PHP worker can die with exit code 137 when it hits that ceiling, instead of the old "Allowed memory size exhausted" message. That is PHP tracker #24492, still open. It is a patch side effect, not proof that someone got in.

CrowdStrike's earlier note said most public proof-of-concepts only crashed PHP. Rapid7 and CISA's 23 October updates described no confirmed mass compromise for typical sites. That picture has moved on — see the 27 October update below. The everyday job is unchanged: get on a fixed build, or ask your host whether yours already has the 21 October fixes.

Rather not run the PHP upgrade yourself? When we do that work we test on staging first, keep a rollback point, charge a fixed price for the quoted job, and quote any extras before we touch the live site. See services and pricing, or email hello@crawlcare.com.

Not sure what your server reports? Run the free PHP2Shell check, or jump to what to do today.

Update, 26 October: a public exploit exists

A public working exploit for PHP builds without the 21 October fixes has been available since 25 October. That was already enough reason to treat patching as urgent. The 27 October update below is the sharper picture.

Update, 27 October: first confirmed break-in

On 26 October, BleepingComputer reported the first solid confirmation of PHP2Shell being used for real remote code execution. Adel Karimi at Perplexity caught it on a honeypot running PHP 8.4.26 under Apache mod_php. Marcus Hutchins at Expel called it the highest-quality confirmation so far. Karimi is clear it was an easy single-worker setup, not a measure of how well the same chain works everywhere.

Attack traffic is still rising. Suzu Labs, quoting Delft Threat Intelligence Lab honeypots via SC Media, logged more than 50,000 PHP2Shell requests from over 600 addresses in 70 countries by the morning of 26 October, with the busiest hour that morning and more sources sending real payloads. Those numbers come from one firm's honeypots, not a public dataset. Security firms also say they hold private exploits that work against normal production settings, including WordPress. Those claims are second-hand; the firms have not published the exploits.

There is still no confirmed mass compromise of everyday sites. Unit 42 has also walked back an earlier claim that a European government agency attack used PHP2Shell. So the hedge stays: confirmed break-ins on honeypots, rising attack traffic, no mass event reported yet.

If you are still without the 21 October fixes, get onto 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or ask your host whether yours already has those fixes. On 8.1 or older, move to a supported version.

In Australia, business.gov.au (23 October) told small businesses to check that their web developer, website host or IT provider has applied the patches — or consider taking the site offline until they can. Our free PHP2Shell check is a quick way to see what your server reports, then ask your host the right question.

Not sure what your server reports? Run the free PHP2Shell check, or jump to what to do today.

What php.net has said

The advance notice on php.net says the release fixes two critical vulnerabilities, both rated 9.2 on CVSS v4.0, and that everyone running PHP should get ready to upgrade as soon as it lands. It also says the team may release early if details leak or the bugs start being used in the wild. The release landed on 21 October with the details.

What the release says: both bugs can let an attacker run their own code on your server without logging in. One comes from how PHP handles running out of memory while a request is still being set up. The other comes from leftover data from an earlier request that a later one can pick up after its memory has been freed. php.net rates the risk highest on Apache with mod_php, where a request can trigger it before WordPress or any of your code even runs.

Which versions are affected: php.net says every PHP install that serves web pages is at risk, whether it runs through PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed. On 8.2 to 8.5, anything older than 8.2.35, 8.3.36, 8.4.27 or 8.5.12 doesn't have the fix.

If your host can't update straight away, php.net lists a few settings that cut down some of the attack paths, like turning off session.upload_progress.enabled and setting a lower post_max_size. It's also clear that none of them make a site safe. Only the update does.

What about PHP 8.1 and older?

Every PHP branch gets two years of full support, then two more years of fixes for critical security issues only. After that it's end of life, and php.net stops shipping fixes for it. Going by php.net's supported versions page, the branches still getting security fixes today are 8.2, 8.3, 8.4 and 8.5. That means 8.1, 8.0, 7.4 and anything older don't get an official release this time either.

This one is serious enough that php.net did a bit extra. The PHP security team put out minimal source patches for 7.4, 8.0 and 8.1, aimed at people who build PHP themselves or can't get a vendor build. Some Linux distributions and long-term support vendors backport fixes too. So your host might be able to patch an old version, but that's up to them, and php.net's advice is to ask your vendor or move to a supported version.

Moving to a supported branch is still the real fix, and that can break an old theme or plugin, which is exactly why so many small business sites are still stuck there. Heads up for 8.2 too: php.net lists its security support ending on 31 December 2026, so it's worth planning the next move now.

The versions php.net released on 21 October: 8.2.35, 8.3.36, 8.4.27 and 8.5.12.

How to check your PHP version

  1. In WordPress: go to Tools > Site Health > Info and open Server. The PHP version is listed there.
  2. In your hosting panel: most hosts show it under a "PHP version" or "PHP configuration" setting, usually with a dropdown to change it.
  3. Compare your version with the fixed versions above. Lower than the fixed version on your branch? Ask your host when they're updating.

Changing branches, say from 8.1 to 8.3, is a bigger job than a patch. Take a backup first, switch on a staging copy if your host offers one, and click through your key pages and forms before you switch the live site.

Has your host patched PHP2Shell?

If your host runs PHP for you, installing the fix is their job, but it's worth knowing where they stand. Here's what four big international hosts have said on their own pages, checked on 22 October 2026. South African hosts are further down.

  • Hostinger: on every plan except VPS, there's nothing for you to do. Hostinger says the exploit code going around didn't work on its servers, its firewall blocks matching requests and it's installing PHP's fix everywhere. On a VPS you run PHP yourself, so you update it and restart it. Hostinger's post
  • WP Engine: says it finished rolling out the patches on 21 October (US time) and you don't need to do anything. It lists the updated versions as 7.4.33.17, 8.2.35, 8.4.27 and 8.5.12. WP Engine's status page
  • SiteGround: says it switched off the affected PHP features on all its servers before the release, so customers don't need to change anything. Its post was last updated at 11:30 UTC on 21 October, before php.net's release, and doesn't name patched versions. SiteGround's post
  • Kinsta: its status page says patches are rolling out for PHP 7.4 to 8.5, and its Cloudflare firewall rules stay on for every site until further notice. The latest update when we checked was 22 October, 03:31 SAST. Kinsta's status page

Behind Cloudflare? Cloudflare says its firewall rules for these bugs are on by default for every plan with its WAF, free plans included. Handy, but Cloudflare also says you still need to patch PHP, and the rules only see requests that pass through Cloudflare. Anyone who reaches your server directly skips them. Treat it as a stopgap.

South African hosts: who's said what

We checked again on 23 October 2026. Two hosts have their own posts, two we only know about through MyBroadband, one posted on the MyBroadband forum, and three have said nothing we could find.

  • xneelo: its own post on 22 October says its firewall on managed servers added cover before the patches came out, and that it applied PHP's updates across its hosting servers as soon as they were released. It also lists checks for your developer: admin accounts and plugins you don't recognise, odd files in upload folders, fresh passwords with two-factor login, and cron jobs you didn't set up. xneelo's post
  • 1-grid: its own blog post on 22 October is an explainer for owners. It doesn't say whether 1-grid's servers are done, and it tells customers to contact support to confirm. MyBroadband reported the same day that 1-grid was still assessing the impact and applying updates, and that it recommends PHP 8.3 or newer. 1-grid's post, MyBroadband
  • Afrihost: we only know this through MyBroadband, which quoted Afrihost's notice to customers. It said it was patching its managed and shared servers and told sites not to run anything lower than PHP 8.2.35. We couldn't find a public page from Afrihost itself. MyBroadband
  • Axxess: same deal. MyBroadband says Axxess sent its customers the same notice as Afrihost. We couldn't find a public page from Axxess either. MyBroadband
  • Absolute Hosting: posted on the MyBroadband forum that patching is done on all its DirectAdmin and cPanel servers, and that sites on end-of-life PHP were moved up to supported, patched versions. Running old code, plugins or themes? Your site might need some fixing after that bump. Absolute Hosting's forum post
  • HOSTAFRICA, Domains.co.za and Webafrica: nothing public that we could find on 23 October. That doesn't mean they haven't patched. It means you'll have to ask.

Host says it's patched, but your version number didn't change?

That can be totally fine. Plenty of hosts patch the PHP they already run and keep the old number. Hostinger says the fix on its managed hosting is built into the version your site already runs, "so the version number may not change". VentraIP in Australia says the same about its CloudLinux builds: its PHP 8.4 still shows 8.4.26, not 8.4.27, even with the fix in. WP Engine's 7.4.33.17 is another example, since php.net never released a version with that number. So an older number in Site Health doesn't prove you're exposed. It doesn't prove you're safe either.

Check the Build Date. It tells you when your PHP was built. Hostinger says a Build Date of 21 October 2026 or later means your site has the fix. Here's where to find it:

  • On Hostinger: hPanel, then Websites, Dashboard, PHP Info.
  • Anywhere else: look for a "PHP Info" page in your hosting panel. No luck? Make a file called info.php that contains <?php phpinfo();, upload it to your site, open it in your browser and find Build Date near the top. Then delete it straight away, because it tells strangers a lot about your server.
  • Got SSH? VentraIP suggests php -v, which shows the build time too. The command-line PHP isn't always the one serving your site, though.

On other hosts a recent build date is a good sign, not proof. Only your host knows what went into their build, so ask them. Copy and paste this:

Hi, does the PHP running my site [yourdomain.co.za] include the 21 October 2026 fixes for CVE-2026-109618 and CVE-2026-109619 (PHP2Shell)? If it's a backported build that kept the old version number, please confirm its build date. If it isn't patched yet, when will it be?

Want a quick hint? Our free scan reads the PHP version your server sends in its X-Powered-By header, if it sends one. If that number is below the fix for your branch, it tells you to ask your host. It can't see a patch that kept the old number, so a flag means "ask your host", not "you've been hacked".

Can't patch, or stuck on PHP 8.1 or older?

The US Cybersecurity and Infrastructure Security Agency (CISA) doesn't mince words. On 21 October it said organisations that can't update straight away, or that still run PHP 8.1 or an older unsupported version, should take their PHP systems offline until they're patched or updated. It adds that a web application firewall may give some protection in the meantime, and that you should watch for PHP processes starting shells or downloading tools.

Pulling your business site offline is a big ask, we know. That's just how seriously they're taking it. If your host bumps you to a newer PHP (like Absolute Hosting did) and something breaks, that's fixable. Getting hacked while you wait is a much worse week.

Attacks started on 17 October. Check nothing got in

Amazon's threat team caught an attempt to use PHP2Shell on 17 October, four days before the bugs went public, and says investigations should start from 17 October, not the release date. A patch closes the hole. It doesn't undo anything that got in before.

That's what our PHP2Shell confirm + compromise check is for. One fixed price: R1,490, $79 or £65. Here's what we do:

  • Confirm whether your PHP has the fix, from your hosting panel (version and build date) or by asking your host for you.
  • Look for signs of an attack from 17 October onward: new or changed admin accounts, plugins and files you don't recognise (upload folders and mu-plugins included), recently changed core files and wp-config.php, odd cron jobs, and your server logs if your host keeps them.
  • Send you a plain-English report of what we found and what we'd do next.

That's it. It's a check, so we don't promise your site is clean or that it'll stay that way. If we find something, cleaning it up is a separate job, and that's Hack Rescue.

Book the PHP2Shell check

On PHP 8.1 or older? Patching alone isn't enough: those branches are end of life. See is my PHP version end of life? How to upgrade WordPress.

What to do today

  • On 8.2, 8.3, 8.4 or 8.5: check your host has applied the update (or ask them), then carry on with your day.
  • On 8.1 or older: ask your host whether they've patched your version, and plan the move to a supported one this week. If an old plugin or theme is holding you back, that's the thing to sort out.
  • Not sure what you're on? The Site Health screen above tells you in a minute.
  • Moving hosts? Update migration plugins first (Duplicator 5.0+, Prime Mover 2.2.2+) and clear held spam comments before you export or restore. Both had critical bugs closed this month.

Rather not do the PHP upgrade yourself? We can test your site on a newer version, fix what breaks and switch it over for you. See our services or pricing. And our free scan checks your site's speed, SEO basics and security headers while you're at it.

Keeping an eye on plugins too? These are this month's other big ones: the UpdraftCentral hack, Rank Math PRO, Backuply and Everest Backup and AIOSEO and Bricksforge. Or paste your address into the WordPress plugin check.

Quick answers

Is my WordPress site affected?

It depends on your PHP version, not your WordPress version. php.net says every PHP install that serves web pages is at risk, so if your site runs anything older than 8.2.35, 8.3.36, 8.4.27 or 8.5.12, it needs the update.

My host manages PHP. Do I need to do anything?

Yes — check they've updated. The first real PHP2Shell break-in was confirmed on 26 October, and attack traffic is still rising, so getting patched is no longer optional. If you're on 8.1 or older, PHP won't ship an official update for your version, so unless your host uses a build with the fix backported, moving up a version is the real fix.

My host says it's patched, but my PHP version is still the old number. Is that OK?

It can be. Hostinger and VentraIP both patch PHP without changing the version number. Check the Build Date on your PHP Info page, and ask your host to confirm their build has the 21 October fixes.

Is my PHP site vulnerable to PHP2Shell?

Only if it runs a version without the fix. On 8.2 to 8.5, that's anything below 8.2.35, 8.3.36, 8.4.27 or 8.5.12, unless your host patched it without changing the version number (some do). 8.1 and older don't get an official release, so they only have the fix if your host applied php.net's source patches or a vendor build.

How do I patch PHP2Shell?

On shared or managed hosting, your host does it. Check your version or Build Date, and ask them if you're not sure. On your own VPS, install the updated PHP package from your distribution or vendor (or build 8.2.35, 8.3.36, 8.4.27 or 8.5.12), then restart PHP so the new build is the one running. On 8.1 or older, the real fix is moving to a supported version. The steps are under what to do today.

How can I check for PHP2Shell?

Compare your PHP version (WordPress Site Health or your hosting panel) with the fixed versions above. If the number looks old, check the Build Date or send your host the question above. Our free scan reads the version your server reports, if it reports one. Want us to confirm the patch and look for signs of attack since 17 October? That's the PHP2Shell confirm + compromise check.

What are the PHP2Shell CVE numbers?

There are two, both listed by php.net: CVE-2026-109618 for the out-of-memory bug and CVE-2026-109619 for the leftover-data bug.

Sources

Further reading