On 21 October 2026 PHP released fixes for two critical flaws in PHP itself, rated 9.2 out of 10 and nicknamed PHP2Shell after a proof-of-concept tool shown in a video that circulated online. The fixed versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, published at 14:34 UK time, about 25 minutes ahead of schedule. News of the flaws leaked the day before, and attack attempts were reported by the following morning.
Note
If your site is hosted with us, patches are being applied when and where possible across our affected services. Check our server status page for further details.
PHP runs WordPress, WooCommerce, Laravel, Magento, Joomla, Drupal and WHMCS, along with a large share of the web’s other sites and shops. That puts this on almost every hosting account, whether or not you’ve ever written a line of code.
What has happened
PHP’s security advisory confirms two separate flaws. CVE-2026-109618 is in how PHP handles running out of memory while a request is still being set up. CVE-2026-109619 is internal state left behind by one request, which a later request on the same server process can reuse.
The EU’s computer emergency response team, CERT-EU, describes the risk as unauthenticated remote code execution. In plain terms, an attacker anywhere on the internet could make a vulnerable server run their own code without logging in to anything.
PHP says every installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates the risk highest for mod_php, where a demonstrated attack runs before any of your site’s code.
The NCSC’s alert asks UK organisations to update every system running PHP, starting with those facing the internet, and to take a system offline if it can’t be fixed straight away. It also asks you to watch for updates from suppliers whose products have PHP built in, such as some network equipment and hosted business tools.
Which websites are affected
The flaws are in PHP, the language that runs your site’s code, and not in the site’s own software. Updating WordPress or a plugin won’t close them, and neither will a security plugin or a firewall rule inside your application. All of them run after PHP has read the incoming request, and PHP’s advisory confirms that on the most exposed setups an attack runs before any of your site’s code does.
So what matters is which version of PHP your site runs, and who updates it. PHP’s supported versions page shows that only PHP 8.2 and newer still get security fixes, and those are the versions PHP has patched.
PHP 8.1 and anything older reached end of life before this happened and got no official release. If you’re moving up, PHP 8.2’s own security support ends on 31 December 2026, so 8.3 or newer will last longer.
That leaves a large part of the web without an official release. According to W3Techs, which surveys over 20 million websites, about half of sites running PHP use version 8.1 or older. A third run 7.4, 8.0 or 8.1, which PHP’s source patches cover if you build PHP yourself or your vendor packages them. The rest, about 15%, run PHP 5 or 7.0 to 7.3, which nothing covers.
The application on top doesn’t change any of this. Shops and billing systems hold customer and payment records, so take a fresh database backup before PHP is updated. Laravel sites need Octane and queue workers restarted after patching, or they’ll keep running the old code.
If your website is hosted with us
One commenter on Ars Technica’s forum summed up how this feels from the customer’s side: “I can’t decide if I’m happy that the ‘shared responsibility’ model makes this Somebody Else’s Problem, or terrified that I’m reliant on somebody else to deal with it quickly and correctly.”
For our web hosting, reseller hosting and other shared hosting customers, patching PHP is our end. We’re applying patches when and where possible across our affected shared and reseller hosting, with mitigations in place wherever a patch isn’t on yet.
PHP on our shared and reseller servers comes from our control panel and operating system vendors’ own builds, so we apply their patched packages and won’t be compiling PHP ourselves. Progress is on our server status page. Mitigations reduce the risk in the meantime, but only the patched PHP fixes this.
The one thing only you can do is check which PHP version your site runs. If it’s 8.2 or newer, there’s nothing else to do. If it’s 8.1 or older, move up to a supported version now, ideally 8.3 or newer, because no further fixes are coming for yours.
You can change it per domain in cPanel by following our guide to changing your PHP version. Older plugins and themes sometimes break on a newer PHP, so test on a staging copy first if you can, and keep a backup either way.
You may see advice online to block file uploads or form submissions at the server. On a hosting account that would break contact forms and checkout pages, and it’s work for whoever runs the server. Leave it to us.
If you run your own VPS
With VPS hosting you have root access, so patching PHP is in your hands. Our support team will help if you ask, but we don’t manage a VPS without your instruction. Install the update now, either PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or your distribution’s patched package, which PHP says distributions received in advance.
Then check the installed package version. Debian, for one, backports security fixes to the version it already ships, so the PHP version number may not change. Compare against your distribution’s security notice, not against php.net.
If you install PHP from Remi’s repository on AlmaLinux, Rocky or another Red Hat family system, the PHP Foundation said that repository wouldn’t have updates on 21 October, and suggests moving to your distribution’s own packages or building from source. After any upgrade, restart PHP-FPM and every long-running PHP process, because they keep the old code in memory until they restart.
If you can’t update straight away, PHP’s advisory lists measures that reduce exposure without making a server safe. None of them replaces the update.
- Turn off upload progress. Set
session.upload_progress.enabledto off inphp.inior the PHP-FPM pool, not withini_set()or an FPM.user.inifile, then restart every worker. It blocks only one confirmed route for one of the two flaws. - Lower request limits. PHP suggests a low
post_max_sizeand limits at the web server on request size and form fields. - Block multipart requests at the web server. This goes further, but it breaks file uploads and many ordinary forms. Mattias Geniar has published tested configurations and their side effects.
If you’re a reseller
Your clients will look to you first, and most of them won’t know what PHP is. Tell them what’s happening and where to follow progress. Then check which of your accounts still run PHP 8.1 or older and help those clients move up.
Our guide to managing your clients covers working with their accounts from WHM. If you run WHMCS for billing, give it the same check.
Advice to ignore
Some advice circulating on social media is wrong.
- That only the old php-cgi handler is affected. PHP lists every common setup as at risk.
- That you should block every request carrying PHP’s session cookie. That would lock out every logged-in visitor and every shopper with a basket.
- That the flaws are rated 10 out of 10. The official severity is 9.2.
- That a failed test of the public exploit means you’re safe. It doesn’t.
Security researcher Christopher Kunz found that the public exploit was built for a LiteSpeed setup and failed against standard PHP-FPM on Ubuntu. PHP says one of the routes was confirmed against PHP-FPM all the same, so a script that fails on your server tells you nothing about whether the flaws can reach it.
After the patch
Patching closes the hole but doesn’t remove anything an attacker planted before it closed. PHP has published the technical details but no signs of compromise, and it warns that one of the flaws can be exploited without a predictable log entry, so a clean log isn’t proof.
Watch for files you don’t recognise and admin accounts nobody created. If you use WordPress, our guide to removing malware from WordPress walks you through the checks. If you need to restore, use a backup from before 20 October, because a newer one could include files an attacker planted.
If an attacker could have reached customer data, such as orders in a shop, UK GDPR may require you to report it. The ICO says that if a breach is likely to put people at risk, you must tell it as soon as possible and, where feasible, within 72 hours.
How the leak unfolded
The story moved from a leak to reported attack attempts in under a day, and PHP brought its release forward by a day as a result. All times are UK time.
- 20 October, about 16.00. The two CVE numbers begin circulating online, with a wrong release time and a wrong severity score of 10.
- 20 October, 20.30. PHP publishes its pre-announcement and moves the release forward from 22 to 21 October.
- 20 October, about 21.00. Calif, one of the security firms that reported the flaws, publishes a proof-of-concept video by mistake.
- 21 October, 08.41. Chainguard publishes patched images six hours before the coordinated release, breaking the embargo.
- 21 October, 08.43. Cloudflare’s chief technology officer reports early attacks.
- 21 October, 09.49. The PHP Foundation warns that Remi’s repository won’t have updates that day.
- 21 October, 10.26. CloudLinux reports attack attempts and ships an interim firewall rule.
- 21 October. The NCSC publishes its alert telling UK organisations to prepare to update PHP immediately.
- 21 October, 14.34. PHP releases 8.2.35, 8.3.36, 8.4.27 and 8.5.12, about 25 minutes early.
Common questions
Quick answers to the questions site owners kept asking once the leak broke.
Is my WordPress site affected?
Yes, if its server runs a version of PHP that hasn’t been patched. PHP handles every request before WordPress loads. Your WordPress version makes no difference here. Make sure the site runs PHP 8.2 or newer.
Will a security plugin protect me?
Not from this. A security plugin runs inside WordPress, which only starts once PHP has read the request, and the attack can happen during that reading. Keep it anyway for the attacks it was built for.
I’m on shared hosting. Do I need to do anything?
Only one thing. Check that your site runs PHP 8.2 or newer, and move it up in cPanel if it doesn’t. Patching PHP itself is your host’s job, and if you’re with us, progress is on our server status page.
My site runs PHP 8.1 or older. What now?
Move it to 8.3 or newer when you can, because 8.1 and older get no further fixes. PHP did publish source patches for 7.4 to 8.1, and some vendors package them, so ask your host whether your version is covered in the meantime. PHP 5 and 7.0 to 7.3 have no fix at all. Back up and test the upgrade on a staging copy first. Older plugins and themes sometimes break.
Is Cloudflare enough?
It helps until you’ve updated. Cloudflare has rules for the known attack on every plan, the free one included, so check they aren’t switched off or set to log only. They only see traffic that goes through Cloudflare, so if your server answers requests sent straight to its address, lock it to Cloudflare’s traffic.
Should I take my site offline?
Only if you can’t patch it and can live with the downtime, which matches the NCSC’s advice. On your own server, stop the web server or serve a maintenance page for every request. Don’t just switch off the PHP handler; in Mattias Geniar’s tests, that left the site’s code, passwords included, readable by anyone.
Do I need to change my passwords?
If you’ve seen signs of compromise, or your site ran unpatched PHP after attacks began on 21 October, treat its secrets as exposed. An attacker who can run code on your server can read the configuration files where they live. Change your database password, API keys and admin passwords, and on WordPress, regenerate the security keys in wp-config.php. Your visitors don’t need to do anything because of this alone.
What to do now
Check your site’s PHP version today, and move it to 8.2 or newer if it’s 8.1 or older.
On our shared or reseller hosting, leave the patching to us and keep an eye on the status page. On your own server, install the update now, restart PHP, and decide whether anything that can’t be patched today should come offline until it can.
