PHP2Shell: The Critical PHP Vulnerability, What It Means for Your Website, and How to Update

On 21 October 2026 the PHP project released emergency fixes for two critical flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed "PHP2Shell". Details leaked a day before the official release, and attack traffic was reported within hours of the patches going out.

PHP runs a large share of the web: WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel apps and countless custom sites. Because these bugs are in the language rather than in any one plugin or CMS, almost every PHP website is affected until its server is updated.

Here's what the vulnerability is, what it could mean for your site, and exactly how to make sure you're patched.

What PHP2Shell is, in plain English

Both flaws are in the way PHP handles incoming web requests, before your site's own code even gets a say.

• CVE-2026-109618 involves how PHP recovers when a request runs it out of memory. A carefully crafted request can leave PHP's internal data half-built, which an attacker can turn into control of the server process.
• CVE-2026-109619 involves information from one request surviving into the next after it should have been thrown away. Among other routes, it can be reached through PHP's session upload-progress feature, which is switched on by default.

The PHP security team rates both as critical (CVSS 9.2). The headline facts:

• No login is needed. An attacker only has to be able to send requests to your website, which means anyone on the internet.
• The result can be full remote code execution: the attacker runs their own code on your server with the same access as your website.
• Memory can leak. Researchers also showed that worker memory can be read without logging in. That memory can hold database passwords, API keys and session tokens.
• Every common setup is exposed. The advisory names PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Apache with mod_php is singled out as the highest risk, because an attack can fire before any application code runs.

Is my website affected?

If your site runs on PHP and the server has not been updated since 21 October 2026, assume yes. Researchers report that at least one of the two issues affects every PHP version back to 5.4.

The fixed releases are:

• PHP 8.5.12 or later
• PHP 8.4.27 or later
• PHP 8.3.36 or later
• PHP 8.2.35 or later

PHP 8.1 and older no longer get regular updates from the PHP project. There is no simple version number to upgrade to on those branches. You need a patched build from your Linux distribution or hosting vendor, or (better) a move to a supported PHP version.

One wrinkle: Linux distributions such as Ubuntu, Debian and Red Hat often backport security fixes without changing the headline version number. On those systems, check your vendor's security notice for the patched package version rather than relying on php -v alone.

What could happen to an unpatched site

This is the kind of bug automated attack tools are built for. There is nothing to guess and no password to steal first, so expect scanning across the whole internet rather than attacks on a chosen few. In practice, a compromised PHP site typically ends up with:

• Backdoors hidden in the site files so the attacker can come back after you update.
• Stolen credentials: the database password from wp-config.php or .env, payment and email API keys, admin session cookies.
• Spam and phishing pages planted on your domain, which can get your site flagged by Google and your emails sent to junk.
• Customer data exposure, with the legal and reputational fallout that follows, especially for shops and membership sites.
• Your server used against others: sending spam, mining cryptocurrency or joining attacks on other sites.

Updating PHP closes the hole, but it does not remove anything an attacker already planted. That's why the last section of this article matters.

How to update

How you update depends on who runs your server. Find your situation below.

Shared or managed hosting

Your host controls the PHP software, so they have to apply the fix. You can still check:

1. Look for an announcement from your host about CVE-2026-109618 / CVE-2026-109619, or ask their support directly whether your server has the patched PHP.
2. In your control panel (cPanel's MultiPHP Manager, Plesk's PHP Settings, or your host's equivalent), check which PHP version your site uses. If it's 8.1 or older, switch to a supported version (8.3 or 8.4 are safe choices for most WordPress sites) after testing on a staging copy.
3. If your host can't say when they'll patch, take that seriously. This is a critical, actively attacked bug.

Your own server or VPS

Use your distribution's package manager, then restart every PHP process. Updating the files on disk does not fix PHP processes that are already running.

Ubuntu / Debian:

sudo apt update
sudo apt install --only-upgrade 'php*'
sudo systemctl restart php8.3-fpm   # match your version, or: sudo systemctl restart apache2

AlmaLinux / Rocky / RHEL:

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm   # or: sudo systemctl restart httpd

cPanel / WHM servers: update the ea-php packages (WHM's update tools or dnf upgrade 'ea-php*'), then restart PHP-FPM and Apache.

LiteSpeed / OpenLiteSpeed: update the lsphp packages for every PHP version you have installed (for example lsphp83), then restart LiteSpeed so the PHP workers reload.

Windows: download the fixed build from windows.php.net, replace your PHP folder, and restart IIS or your web server.

If your distribution hasn't published a patched package yet, check again every few hours and use the temporary measures below in the meantime.

Docker and containers

Containers are easy to forget, because each one carries its own copy of PHP. Updating the host does nothing for them.

1. Pull the fixed official image, for example php:8.3-apache or php:8.3-fpm, which now ship 8.3.36. If you pin exact versions, bump the tag to a fixed release.
2. Rebuild any custom images with --pull so they pick up the new base.
3. Recreate the containers. Restarting an old container keeps the old PHP.
4. Confirm inside each one: docker exec <container> php -v

Check that it worked

• Run php -v on the server or in each container and compare against the fixed versions above, or against your distribution's patched package version.
• Remember the command-line PHP and the PHP serving your website can be different installs. Your control panel, or WordPress under Tools → Site Health → Info → Server, shows the version the website actually uses.
• Don't forget staging sites, old test installs and any appliance or software that bundles its own PHP. Attackers scan for those too.

If you can't update straight away

The PHP team is clear that updating is the only complete fix. These measures reduce risk while you arrange it, but they do not make a server safe:

• Put the site behind a web application firewall. Cloudflare and other providers have shipped rules targeting these attacks.
• Turn off the session upload-progress feature by setting session.upload_progress.enabled = 0 in php.ini or the PHP-FPM pool config (not in .user.ini or code), then restart every PHP worker.
• Limit request sizes: keep post_max_size and upload_max_filesize as small as your site allows, and enforce request size limits at the web server or proxy too.
• For a high-risk site that can't be patched, consider maintenance mode or restricting access until it can.

Avoid "fix" plugins and code snippets doing the rounds. They're unverified, can't actually repair PHP itself, and can break your site.

After patching: check for signs of compromise

Because attacks started before many servers could be updated, and because the bug can leak secrets from memory, a careful clean-up is worth the effort.

• Rotate secrets the site holds: database passwords, API keys (payment, email, cloud storage) and the WordPress salts in wp-config.php, which also signs everyone out.
• Look for new admin users and unfamiliar plugins, and for recently modified PHP files, especially in uploads folders where PHP files should never appear.
• Check your logs for unusual multipart requests followed by memory-limit errors or bursts of HTTP 500 responses, oversized or malformed PHPSESSID cookies, and unexplained PHP worker restarts. None of these proves an attack, but they're worth a closer look.
• Run a malware scan and confirm your backups are recent, so you have a clean copy to restore if you find something.

The bigger lesson

Most website security advice focuses on plugins, themes and passwords, and rightly so. PHP2Shell is a reminder that the software underneath your site matters just as much. A fully updated WordPress install is still exposed if the PHP running it is out of date.

Good hosting is what closes that gap: someone watching security advisories, patching the server and containers within hours rather than weeks, and keeping supported PHP versions in place before the old ones run out of road.

If you're not sure whether your site is patched, or you'd like a second pair of eyes after an incident like this, get in touch. You can also run a free site audit to see how your site looks from the outside.