php2shell: the critical PHP vulnerability and what to do now

php2shell is the name researchers have given to two critical vulnerabilities in PHP, the language behind WordPress, Laravel and most sites running on their own server. The PHP security team will release the fix on Wednesday 21 October 2026 at 14:00 UTC. According to researchers who have seen the details, an attacker can run their own code on the server without logging in. Update PHP the day the fix lands, or ask whoever runs your server to confirm they have. We'll update this article once PHP publishes the details.

Status 21 October 2026, 09:45 UTC: PHP has announced the release but hasn't yet published technical details, affected versions or the fixed version numbers. Everything below about the bug itself comes from leaks and security firms, and we say so where it does.

What is php2shell?

The two vulnerabilities are CVE-2026-109618 and CVE-2026-109619. PHP rates both 9.2 out of 10 on CVSS v4.0. The name isn't PHP's own. It describes what a successful attack gets you: a shell on the server.

The leaks place the bug in the code that tracks upload progress, session.upload_progress. It's a use-after-free: PHP keeps using a piece of memory after freeing it, and an attacker can fill that memory with data of their choosing. One researcher claims a second route in, through the parser that reads multipart form data.

If the leaks are accurate, this is about as bad as a PHP bug gets:

• A single POST request is enough, and no login is needed.
• The feature is on by default and runs even if your site has no upload form at all.
• The bug fires while PHP parses the request, before WordPress, Laravel or any other framework runs a single line.

watchTowr has confirmed the vulnerabilities are real. A researcher has shared a log showing a command running as www-data on Ubuntu 26.04 with PHP 8.5.4 and Apache. GMO Flatt Security reports that code claiming to exploit the bug is already circulating.

Is your site affected by php2shell?

Probably, if it runs on PHP and PHP hasn't been updated since 21 October. W3Techs puts PHP behind 69.3% of websites whose server-side language is known. That covers WordPress and WooCommerce, Drupal, Joomla and Magento, plus anything built with Laravel, Symfony or plain PHP. According to Flatt Security, one researcher reproduced the attack on WordPress, Laravel and Symfony, under both Apache and PHP-FPM.

Keeping WordPress and its plugins up to date won't help here. The bug is in PHP itself and triggers before a security plugin such as Wordfence gets to see the request. Only a patched PHP build on the server closes it.

Who does the work depends on where the site lives:

Large hosting providers patch PHP centrally for every shared hosting customer, usually within a couple of days. In our view the real risk sits with servers nobody clearly owns. Think of a VPS a previous agency set up in 2019, a Docker image pinned to php:7.4-apache, or an old campaign site on a subdomain everyone has forgotten about.

How to protect your site from php2shell

1. Find out who updates PHP. If you pay for shared hosting, it's your hosting provider. If you're not sure, our knowledge base explains how to find out who hosts your website.
2. Check your PHP version. In WordPress it's under Tools → Site Health → Info → Server. The last releases before the fix are 8.2.34, 8.3.35, 8.4.26 and 8.5.11, and PHP publishes the fixed versions at 14:00 UTC. We'll add them here as soon as they're out. Ubuntu and Debian often patch their own PHP packages without changing the version number, so on those systems check the package changelog instead.
3. Patch the same day, then restart PHP. An updated package on disk protects nothing until every process holding PHP in memory has restarted. That means PHP-FPM and Apache, but also queue workers and application servers such as Laravel Octane and FrankenPHP. Our knowledge base has the steps for shared hosting, Ubuntu, Debian and Docker: how to patch PHP for php2shell.
4. Turn off session.upload_progress until you've patched. Add session.upload_progress.enabled = 0 to php.ini and restart PHP. You can't change this setting with ini_set() from your code. Without access to php.ini, the same line in .user.ini works when PHP runs as PHP-FPM, though it can take up to five minutes to apply. On Apache with mod_php, use php_flag session.upload_progress.enabled off in .htaccess, but that line causes a 500 error if PHP runs as PHP-FPM. Flatt Security describes this as a partial mitigation, so it doesn't replace the patch.
5. Isolate whatever you can't patch. PHP 8.1 and older won't get a fix. CERT-EU recommends taking such services off the public internet until they're upgraded, for instance behind a VPN or restricted to known IP addresses. A firewall in front of the site, such as Cloudflare, only helps if the vendor has shipped a rule for this attack and your server can't be reached directly on its IP address.
6. Look for signs of compromise from 20 October onwards. Keep your logs before you patch, so a deploy or log rotation doesn't wipe them. Look for PHP files in upload folders such as wp-content/uploads, unfamiliar admin users, new cron jobs, and changes to .htaccess, .user.ini or auto_prepend_file. Unknown SSH keys in authorized_keys are a clear sign someone has been on the server. The full walkthrough is in how to check whether your server was attacked through php2shell.

An email you can send your provider

If you don't know whether your server has been patched, send this to your hosting provider or developer:

Hi,

On 21 October 2026 PHP is releasing a security fix for two critical vulnerabilities known as php2shell (CVE-2026-109618 and CVE-2026-109619). Could you confirm the following for [your website address]?

1. Which PHP version does the site run on, and will it receive the fix?
2. When will the fix be installed, and will PHP be restarted afterwards?
3. Have you disabled session.upload_progress or taken other steps until the fix is in place?
4. Are you checking files and logs for signs of compromise since 20 October?

Thanks,
[your name]

If you hear nothing back within a couple of days, or the answers suggest they don't follow the question, that tells you something too. It may be time for someone else to look after the server.

The servers PXL runs get the fix the day PHP releases it. If you're thinking about changing provider, or want someone to look over your server, we'd be glad to talk. We're getting a lot of calls about php2shell right now and have extended our opening hours today and over the next few days, so we'll get back to you as quickly as we can. Call us on +47 40 10 10 30.

Patching doesn't remove an intrusion

The fix closes the hole. It doesn't remove anything an attacker left behind before you patched. After bugs like this, attackers usually drop a web shell, a small PHP file that accepts commands, and come back to it later. That's why many owners only notice weeks afterwards:

• Google shows Japanese search results for your site (the Japanese keyword hack)
• Visitors get redirected to spam or scam pages (spam redirects)
• Admin users you don't recognise appear
• Chrome or Google Search Console flags harmful content (Google warnings)
• The server slows down because someone is mining cryptocurrency on it

Our knowledge base covers the signs that a site has been hacked and how to remove malware. If the attacker got onto the server itself, the safe route is to rebuild the server from a clean backup and rotate every password and key.

How soon will attacks start?

Once the fix is public, anyone can compare the code before and after and work out the bug. That's what happened with CVE-2024-4577, a critical flaw in PHP-CGI on Windows. PHP shipped the fix on 6 June 2024, and Imperva saw attacks from 8 June, including the TellYouThePass ransomware. That bug only affected Windows servers with a specific setup. php2shell, if the leaks hold, affects the default configuration on every platform.

We expect automated attacks within days of 21 October, aimed first at the most common builds: Ubuntu and Debian packages and the official Docker images. Memory corruption bugs are harder to exploit reliably than a simple command injection, so it may take a little longer this time. That's no reason to wait.

PHP 8.1 and older get no fix

PHP only ships security fixes for 8.2, 8.3, 8.4 and 8.5. PHP 8.1 lost security support on 31 December 2025, and PHP 7.4 in November 2022. Even so, W3Techs reports that 27% of PHP sites still run PHP 7 and 7.7% run PHP 5.

If you're upgrading now, skip 8.2. Its security support ends on 31 December 2026, ten weeks from now. WordPress recommends PHP 8.3 or newer, and PHP 8.4 is supported until the end of 2028.

A site on PHP 7.4 hasn't had a security fix for almost four years. php2shell makes that visible, but the problem was already there. What usually blocks the upgrade is old plugins or custom code that won't run on newer PHP. Read more about the PHP version in WordPress and technical debt in WordPress. For custom applications, see how we approach Laravel development.

Changelog

We'll update this article when PHP publishes the details and as news of attacks comes in. Newest entry first.

• 21 October 2026, 09:45 UTC: Published. PHP has announced the security release but not the details or fixed versions.

If you're not sure who's responsible for your server, send us your website address and we'll tell you what we see, with no obligation. Read more about IT security at PXL and WordPress at PXL.

Sources and further reading

• Upcoming Critical PHP Security Release and Supported Versions, php.net
• Security Advisory 2026-018: Critical Vulnerabilities in PHP, CERT-EU
• php2shell overview and recommended actions, GMO Flatt Security (in Japanese)
• Disabling session.upload_progress before the php2shell patch lands, lilting.ch
• Usage statistics of PHP, W3Techs
• PHP command injection flaw exploited to deliver ransomware (CVE-2024-4577), Help Net Security