PHP2Shell: the critical PHP flaw, and how to patch it on your host

Status at 17:00 UK time, 21 October 2026. The fixed PHP versions are out. Attack traffic has already been seen. If your site runs on PHP, update it today. Need it done for you? Tell me which site.

On 21 October 2026 the PHP team released emergency updates for two critical flaws in PHP itself. Researchers call them PHP2Shell. They are tracked as CVE-2026-109618 and CVE-2026-109619, and PHP rates both 9.2 out of 10.

In plain terms: someone can send your web server a specially built request and run their own code on it. They do not need a login. PHP's own advisory says the risk is highest for Apache with mod_php, where a demonstrated exploit fires "before any application code runs". So your WordPress security plugin never gets a look at the request.

PHP runs most of the web. Cloudflare puts it at almost 70% of websites. If your site is WordPress, WooCommerce, Laravel, Drupal, Joomla or Magento, this is about you.

What happened, in order#

• 20 October. Details of the two flaws leaked online before the planned disclosure. The same day, the PHP team announced an emergency release for 21 October at 14:00 UTC.
• 20 to 21 October. CERT-EU and the UK's National Cyber Security Centre (NCSC) published warnings. The NCSC told UK organisations to prepare to update straight away and, where that is not possible, to "consider taking the system offline until it can be fully mitigated".
• 21 October. PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Cloudflare reported that it had already seen attack traffic aimed at its customers, and that attackers were changing their payloads to get past its rules.

What the two flaws are#

Both come from the same root problem. When a PHP request ends badly, PHP can leave its memory in a broken state.

PHP lists every setup that serves web requests as at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

Which version you need#

Two traps here.

First, the PHP version your site uses is often not the one you see on the command line. A server can have three PHP versions installed. php -v in a terminal tells you about the command-line one. Your website may run a different one through PHP-FPM or mod_php. Check the one that serves the site.

Second, Linux distributions patch their own older builds. Ubuntu's notice (USN-8948-1) fixes Ubuntu 24.04's PHP 8.3 as package 8.3.6-0ubuntu0.24.04.13. That build is patched even though php -v still says 8.3.6. Go by your vendor's notice, not by the version number alone.

For PHP 8.1 and older, the PHP team published unofficial source patches for 7.4, 8.0 and 8.1 on GitHub. They help people who compile PHP themselves. For everyone else, the honest answer is that a site on PHP 8.1 or older needs to move to 8.2 or newer, and that move needs testing.

If you cannot update today#

PHP is clear that only the update fixes this. These settings from its advisory reduce exposure to the known attack paths. They do not make the server safe.

• Set session.upload_progress.enabled=0 in php.ini or the FPM pool config, then restart every PHP worker. A .user.ini file or ini_set() is not enough.
• Set memory_limit=-1 in a way the site cannot override, such as php_admin_value in the FPM pool. Then check nothing else sets a limit again.
• Set a low post_max_size: 8M if the site takes no file uploads, 32M if it does. Keep upload_max_filesize below it.
• On PHP 8.5 only, set fatal_error_backtraces=0 and restart the workers.
• If you use Cloudflare, keep the WAF on. Cloudflare says its rules for this flaw are on by default for every plan with the WAF, including Free. Paid plans should check the Managed Ruleset is in block mode.

If none of that is possible and the site holds customer data, the NCSC's advice is to consider taking it offline until you can fix it.

How to patch it on your hosting#

Shared hosting (cPanel, Plesk, most UK web hosts)#

You cannot update PHP yourself on shared hosting. Your host does it. Your job is to check two things and get one answer in writing.

1. In your control panel, find the PHP version for each site. In cPanel this is the "MultiPHP Manager" page. Other panels have a similar PHP settings page.
2. If any site is on PHP 8.1 or older, move it to 8.2 or newer. Test the site afterwards, because old plugins can break on newer PHP.
3. Ask your host: "Has the PHP my site uses been patched for CVE-2026-109618 and CVE-2026-109619, and when?"

cPanel and WHM servers#

CloudLinux posted on its status page at 14:55 UTC on 21 October that patched cPanel ea-php74 to ea-php85 packages were scheduled for EasyApache 4 release v25.91. It said patched builds for every CloudLinux alt-php version from 5.2 to 8.5 would follow. Its Imunify360 firewall rules for the exploit were already live.

If you run the server: update through EasyApache 4 in WHM, or run yum update / apt upgrade once the packages land. Then restart Apache, PHP-FPM or LSAPI. Check every PHP version your sites use, not just the default.

Plesk servers#

Plesk's own advisory lists the fix for PHP on Plesk for Linux as 8.5.12, 8.4.27, 8.3.36 and 8.2.35. At the time of writing, PHP 8.0 and 8.1, all Windows builds, and Plesk's own internal PHP (sw-engine, the PHP that runs the Plesk panel) were marked as in development. The panel fix is planned as hotfix 18.0.80#11 and 18.0.81#4.

The advisory links to Plesk's guide on installing updates. For PHP 5.6, 7.2 and 7.3, Plesk points to paid TuxCare extended support.

Managed WordPress hosting (GoDaddy, WP Engine, Kinsta, SiteGround and others)#

Managed hosts update PHP for you. Do not assume it has happened. GoDaddy published guidance on 20 October telling customers to assume they are affected until updated, and to move off PHP 8.1 or older. Whoever your host is, ask them to confirm in writing that your site's PHP has both fixes.

Updating WordPress, your theme or your plugins does nothing for this flaw. The fix is in the server's PHP.

Laravel Forge#

Forge does not update PHP for you. Its docs say it applies Ubuntu security updates weekly but does not update PHP or MySQL automatically. To patch: open the server, click the Runtime tab, then PHP, open the menu next to each installed version and click Update. Do it for every installed version, not just the default.

In a message quoted by Laravel News, the Laravel team said Laravel Cloud would put patched PHP into its base images, and that you may need to redeploy to pick them up.

Your own Ubuntu or Debian server#

Update every PHP package, then restart PHP-FPM:

# see what is installed
dpkg -l 'php*' | awk '/^ii/ {print $2, $3}'

# update (example for PHP 8.3)
sudo apt update
sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm

If your PHP comes from Ubuntu itself, check the package version against Ubuntu's notice USN-8948-1. If it comes from a third-party repository, check that repository's notice, and confirm php-fpm8.x -v shows the fixed version.

RHEL, AlmaLinux and Rocky#

Run sudo dnf update 'php*', then sudo systemctl restart php-fpm. Check your repository's own security notice for which build carries the fix. A release candidate (an RC build) is not the security release.

Docker#

Pull the new image, rebuild your own images with docker build --pull, then recreate the containers. Restarting an old container leaves the old PHP in it. Run php -v inside the new container to check.

Restart PHP properly#

This is the step people miss. A running PHP process keeps the old, vulnerable code in memory until it restarts. Mattias Geniar published this table on 21 October, and tested the PHP-FPM and Apache rows himself:

Then check the site's PHP version from the web side, not the command line. A one-line phpinfo() file works. Delete it as soon as you have read it.

After patching: check nobody got in first#

Patching stops new attacks. It does not remove anything an attacker already left behind. Attack traffic was seen before the fix was released, so a quick check is worth doing:

• Look for PHP files in places that should only hold images, such as wp-content/uploads.
• Check for admin users you do not recognise, and for scheduled tasks (cron jobs) you did not set up.
• Look through your access logs for large or odd form posts in the days before you patched.
• If anything looks wrong, change your database password, API keys and admin passwords, then get the site properly cleaned.

Get it done for you#

Sources#

Everything above was checked against these pages on 21 October 2026.

• PHP security advisory and release notes, php.net, 21 October 2026: php.net/archive/2026.php
• GitHub advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, PHP project, 21 October 2026
• NCSC alert "Critical security issue affecting PHP", 21 October 2026: ncsc.gov.uk
• CERT-EU security advisory 2026-018, 20 October 2026: cert.europa.eu
• Cloudflare, "Cloudflare deploys protections against php2shell vulnerability", 21 October 2026: blog.cloudflare.com
• Ubuntu security notice USN-8948-1: ubuntu.com
• Plesk advisory for CVE-2026-109618 and CVE-2026-109619: support.plesk.com
• CloudLinux status page incident, updates on 21 October 2026: cloudlinux.statuspage.io
• GoDaddy, "Important PHP security update: What website owners need to do", 20 October 2026: godaddy.com
• Laravel Forge docs, patching PHP versions and automated security updates
• Laravel News, "PHP critical security release": laravel-news.com
• Mattias Geniar, "PHP CVE-2026-109618 and CVE-2026-109619: how to apply the patches", 21 October 2026: ma.ttias.be