PHP2Shell: Critical PHP Vulnerabilities Every Website Owner Must Patch Now

PHP2Shell: Critical PHP Vulnerabilities Every Website Owner Must Patch Now

On 21 October 2026, the PHP project released emergency security updates for two critical flaws. Attackers could use them to run their own code on a web server without logging in. Both are rated 9.2 out of 10 (CVSS v4.0) and are tracked as CVE-2026-109618 and CVE-2026-109619. Researchers nicknamed them PHP2Shell.

If your website runs on PHP, this affects you. Roughly 69.7% of websites with a known server-side language use PHP, including WordPress, Drupal, Joomla and Magento sites.

What happened

The two flaws are in PHP itself, not in a plugin, theme or framework:

• CVE-2026-109618: if a request runs out of memory at the wrong moment, PHP can be left holding half-built internal data and later treat it as valid. That can corrupt memory and lead to code execution.

• CVE-2026-109619: internal state from one request can survive after its memory is freed. A later request handled by the same worker can then use that stale state.

Because the bugs are in PHP's engine, well-written application code does not protect you. PHP says there is no complete workaround, and updating is the only full fix.

The disclosure was also rushed. Details leaked a day early, so PHP shipped the fixes ahead of schedule.

Who is at risk

Any PHP installation that serves web requests is affected. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers mod_php the highest-risk setup, because one unauthenticated request can trigger the attack before any application code runs.

Are attackers using it?

Yes, attackers are already probing for it:

• Amazon Threat Intelligence reported an exploitation attempt on 17 October, four days before the public disclosure.

• Arctic Wolf Labs saw widespread scanning and likely weaponised attempts after disclosure, including payloads linked to a botnet.

• Palo Alto Networks estimates about 22 million internet-facing instances could be exposed.

Attempts are not the same as successful break-ins. But a public proof of concept exists, so assume that attackers are scanning for unpatched servers now.

Which PHP version should you install?

PHP 8.2 reaches end of life on 31 December 2026, so plan an upgrade to 8.3 or newer soon.

How to patch your website

Choose the section that matches your setup. If you are not sure, start with Step 1.

Step 1: Find out what you actually run

• WordPress: go to Tools → Site Health → Info → Server to see your PHP version.

• Server access (SSH): run php -v. This only shows the command-line version. Your website may run a different PHP build, so also check PHP-FPM with php-fpm8.3 -v, replacing 8.3 with your version.

• Not sure who manages it? Ask your hosting provider or developer which PHP version your site uses and whether it has been patched.

Step 2: Apply the update

Shared or managed hosting. Your provider updates PHP, not you. Contact them, ask when the fix will be applied and ask for confirmation. Updating WordPress or its plugins does not fix this, and WordPress has said no WordPress update is required or planned.

Ubuntu or Debian servers (VPS). Install the updated PHP packages from your distribution:

Shell

1. sudo apt update

2. sudo apt upgrade

3. sudo systemctl restart php8.3-fpm # change 8.3 to your PHP version

Ubuntu published security notice USN-8948-1 for these flaws. Ubuntu often backports fixes without changing the upstream version number. For example, a patched Ubuntu 24.04 package reads 8.3.6-0ubuntu0.24.04.13. So php -v showing an older number does not always mean you are unpatched. Check the package version against the notice. Some user-maintained repositories were slow to publish patches, so check them again if the update does not appear.

Laravel Forge servers. Forge's automatic security updates do not patch PHP. Update PHP from the Forge dashboard, then restart long-running PHP processes. Forge installs PHP from Ondřej Surý's package repository, so patched packages may take a short while to appear.

Building from source. Download the 8.5.12, 8.4.27, 8.3.36 or 8.2.35 release from php.net/downloads.php and rebuild.

Windows or XAMPP. Get the matching build from windows.php.net/download/, replace your PHP folder and keep your existing php.ini.

Docker and containers. Rebuild your images from a patched PHP base image and redeploy. Updating packages inside a running container is not enough.

Step 3: Restart PHP and verify

Installing the update is not enough. The old worker processes keep running the vulnerable code until you restart them. Restart PHP-FPM, Apache, php-cgi, FrankenPHP or LiteSpeed, depending on your setup. Then confirm the running version is the patched one.

Older PHP versions (8.1 and below)

PHP 8.1 and older no longer receive official releases. Your options:

1. Upgrade to a supported branch. This is the best fix.

2. Check your Linux distribution or host. They may backport the fix to the old version.

3. Use the source backports. PHP's security team published minimal source backports for PHP 7.4 through 8.1. [tenable.com]

4. Community patches (last resort). A community GitHub project packages emergency patches for old PHP versions. It is not official, so test it on a staging copy before using it on a live site. [github.com]

5. Take the site offline until you can fix it. CISA advises this if you cannot update immediately or are still on PHP 8.1 or earlier. [cisa.gov]

If you cannot patch today

These steps reduce risk but do not replace the update:

• Use a web application firewall (WAF). Cloudflare says its WAF has blocked exploitation attempts by default since 21 October on every plan, including the free one. It also says this comes on top of the fix and does not replace it. [axelites.com]

• Don't rely on a configuration change. An early suggestion to disable session.upload_progress was withdrawn, and a PHP release manager said settings alone won't save you. [cyberkendra.com]

• Isolate internet-facing PHP applications from the public internet until they are patched. [cert.europa.eu]

Check whether you were already attacked

JPCERT/CC lists these warning signs:

• Abnormally long PHPSESSID values

• Suspicious multipart/form-data requests

• Memory limit errors and HTTP 500 errors

• Abnormal termination of PHP workers [note.com]

CISA also advises watching for PHP processes launching shells or downloading tools. If you find any of these, change your passwords, API keys and database credentials, and have your server reviewed. [cisa.gov]

Your PHP security checklist

✅ List every site and server that runs PHP, including old and forgotten ones ✅ Record each PHP version and who is responsible for updating it ✅ Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the distribution's patched package ✅ Restart PHP and confirm the running version ✅ Replace PHP 8.1 and older with a supported version ✅ Add a web application firewall as an extra layer ✅ Review your logs for the warning signs above ✅ Confirm your backups are recent and restorable

How Digitalbes Limited can help

Digitalbes Limited supports businesses, schools and organisations with:

• Emergency PHP patching and verification across websites, portals and custom applications

• Security reviews to find unpatched servers and outdated software

• Website maintenance and support with regular updates, monitoring and backups

• Hosting and server management so PHP updates are handled for you

• Upgrades and migrations for sites still running unsupported PHP versions

👉 Not sure whether your website is patched? Request a security review: www.digitalbes.com/services/maintenance-and-support

Bringing Your Ideas to Digital Life