Critical PHP Vulnerability October 2026: What Happened and How to Protect Your Website

The short version

• On October 21, 2026, PHP released emergency security updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619.
• Both let an attacker run their own code on your web server without logging in.
• If your website runs on PHP, including WordPress, WooCommerce, Drupal and Joomla, it is at risk until the server is updated.
• The fix is PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Updating WordPress or plugins does not fix it.
• If your server was exposed before it was patched, it should also be checked for signs of a break in.

What happened with the PHP vulnerability

PHP is the programming language behind about 70 percent of websites, including every WordPress site. Researchers at the security firm Wiz found two serious bugs in PHP itself and reported them privately to the PHP team. Normally a fix is built quietly and announced once it is ready.

This time the details leaked online on October 20, a day before the fix was ready. The security firm watchTowr confirmed the flaws were real, and the PHP team released emergency updates on October 21.

• CVE-2026-109618: if PHP runs out of memory at the wrong moment, it can be tricked into trusting half built internal data.
• CVE-2026-109619: data left over from one visitor’s request can be picked up by the next request before PHP has cleaned it up.

Both carry a severity score of 9.2 out of 10, which is rated critical.

Why the leak made it worse

Attackers follow the same disclosure channels that security teams do. Once the details of a bug like this are public, it becomes a race between site owners applying the patch and attackers building a working exploit.

Researchers have nicknamed this one php2shell. An attacker sends a specially crafted request to your website and gets a shell on your server, which means they can run whatever commands they want. No password or login is needed.

This pattern is well established. In June 2024 a different PHP flaw, CVE-2024-4577, was being exploited less than 48 hours after its fix was released, and a ransomware group used it to break into servers.

What an attacker can do with a vulnerable PHP server

A typical attack is quiet. Take an online store running WooCommerce. The attacker uses the flaw to drop a small file into the site’s folders with a forgettable name like wp-cache-helper.php. That file is a back door, and from there they can:

• Copy card details from the checkout page as customers type them.
• Steal customer records, passwords and API keys stored on the server.
• Send spam from your server and get your domain blacklisted.
• Add hidden spam pages that damage your Google rankings.
• Stay in place and come back later.

None of this has to change how the site looks. Most owners find out weeks later from a customer, their host or Google.

How attackers find vulnerable websites

Attackers do not need to know who runs PHP. With about 70 percent of websites using it, automated tools scan huge ranges of the internet in hours and try the attack on everything that responds.

High value targets such as banks, government agencies and large retailers draw attention, but they usually have security teams that patch within hours. The sites that get hurt most are small and midsize businesses: online shops, clinics, law firms, agencies and nonprofits whose servers get updated when someone gets around to it. W3Techs data from earlier this year showed roughly four in ten PHP websites still running PHP 7 or older, versions that receive no official fix at all.

Patching PHP does not remove a hacker who is already in

This is the part most people miss. Updating PHP closes the door, but it does not remove anyone who got in before you updated. A back door file, a new admin account or a scheduled task added by an attacker stays exactly where it is.

That leaves two jobs:

1. Patch PHP and restart it, so every running PHP process picks up the fixed version.
2. Check whether anyone got in during the window before the patch, and clean up properly if they did.

Checking for a compromise means reviewing server and access logs for suspicious requests, looking for files that changed when they should not have, checking for new users and scheduled tasks, watching for unusual outgoing traffic, and comparing core files against known good copies.

Restoring from a backup needs care too. A backup taken after the break in contains the back door. The right approach is to identify exactly which files were altered and restore only those from a clean copy, without undoing legitimate changes or taking the site down.

Which PHP versions fix CVE-2026-109618 and CVE-2026-109619

Find the version line your server runs and make sure it is at least the release shown.

The PHP team published minimal source patches for PHP 7.4, 8.0 and 8.1, and some Linux distributions and hosts ship their own patched builds. These versions are past end of life, and this is a good time to move off them.

One note for Ubuntu and Debian users. Your distribution’s own PHP packages may keep their original version number even after the fix is applied. The update checklist below shows how to confirm the patch on those systems.

How to check your PHP version

• WordPress: go to Tools, Site Health, Info and open the Server section.
• Hosting control panel: cPanel, Plesk and most hosts list it under PHP or Software.
• Your own server: run php -v. The command line and the web server can run different versions, so also check the version behind your site, such as your PHP-FPM service on Linux or the PHP version configured in IIS on Windows Server.

What to do right now

1. Update PHP to a fixed version from the table above through your host, control panel or package manager.
2. Restart PHP. Running PHP processes keep using the old code until they restart, which usually means restarting PHP-FPM, Apache or IIS.
3. Check every site and server you own, including staging copies, old installs and anything set up years ago and forgotten.
4. Check for signs of a break in on any server that was exposed before the patch. If anything looks wrong, change passwords and keys, because these flaws can expose data held in server memory.
5. Plan an upgrade for anything still on PHP 8.1 or older, and test the site on the newer version first.

How to update PHP on Ubuntu: a quick checklist

If you manage your own Ubuntu or Debian server, these are the basic commands. Run them over SSH as a user with sudo access, and replace 8.3 with the PHP version your server uses.

1. Check which PHP version you are running

php -v
ls /etc/php/
systemctl list-units --type=service 'php*'

The first command shows the command line version. The other two show which PHP versions are installed and which PHP-FPM services are running, because the version serving your website can be different from the one on the command line.

2. Know the version you need

If you install PHP from the popular ondrej/php repository or from php.net, the version must be at least 8.5.12, 8.4.27, 8.3.36 or 8.2.35 for its line. Ubuntu’s own packages work differently. Ubuntu backports security fixes without changing the main version number, so a patched PHP 8.3 on Ubuntu 24.04 can still report something like 8.3.6. On those packages, check the changelog for the CVE numbers instead:

zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep -E 'CVE-2026-10961[89]'

If that prints nothing after you update, your distribution has not published the fix yet, or the update has not been installed.

3. Install the update

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt upgrade

Review the list before you confirm. apt upgrade updates every package with a pending update, which is normally what you want on a server that is kept current.

4. Restart PHP and confirm

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2
php -v

Restart PHP-FPM if you use it, and Apache if your site runs PHP through mod_php. Then load your website and check that it works. On Windows Server, install the updated PHP build from windows.php.net and restart IIS.

If you compiled PHP from source

A custom built PHP does not update itself. You need to rebuild it from the fixed source release with the same configuration options you used the first time. PHP records those options, so you can retrieve them before you start:

php -i | grep 'Configure Command'
which -a php php-fpm php-cgi

Download the fixed release from php.net, run ./configure with the same arguments, then make and make install. Afterwards, make sure every binary was actually replaced. Custom setups often have more than one copy or use their own names, such as a versioned php83, a separate php-fpm or php-cgi, or an Apache module. Check the version of each one, then restart every service that uses them. Extensions built for the same PHP line normally keep working after a patch release.

Checking for a compromise is a bigger job

Updating takes minutes. Confirming that nobody got in before the update takes longer, because there is no single command for it. It means reviewing logs across the right date range for your server, checking file changes, user accounts, scheduled tasks, SSH keys, running processes and outgoing connections, and comparing all of it against what your server should actually be doing. Attackers can also fake file dates, so timestamps alone are not proof. If your server was exposed, this is the part worth handing to someone who does it regularly.

If you cannot update PHP today

The PHP team lists settings that reduce exposure while an update is arranged. They are a stopgap and do not make a server safe.

• Set session.upload_progress.enabled = 0 and restart every PHP worker.
• Keep post_max_size low, 8M if your site does not accept uploads and 32M if it does.
• On PHP 8.5, also set fatal_error_backtraces = 0.

Avoid “fix” plugins and copied snippets. A plugin cannot patch PHP itself.

Should you take your website offline?

Some advice online says to take your site offline until it is patched. For most sites that costs sales and traffic without fixing anything. In most cases the server can be patched, checked and cleaned while the site stays online.

The exception is a site that is actively compromised, for example one serving malware or skimming card details. Then a short planned outage while it is cleaned is the right call.

Is WordPress affected by the PHP vulnerability?

Yes, if the server it runs on has a vulnerable version of PHP. The flaw sits underneath WordPress, so WordPress core, theme and plugin updates do not fix it. The same goes for Drupal, Joomla, Magento and Laravel.

Frequently asked questions

Get your PHP patched and your server checked

I have spent more than 25 years building websites and running the servers behind them. I can update PHP, check for signs of a break in, clean up anything I find and keep your site online while I do it.

Connect with me on Upwork, or send a message here and it comes straight to my inbox.

Your name Email address

Your website optional How can I help? Leave this field empty Send message >

Your details are only used to reply to you.

About the author

I’m Oliver, the developer and server engineer behind Wild Westbrooks. I have been building websites and managing servers for more than 25 years. Day to day that means custom PHP, WordPress builds and fixes, and senior level server work. I manage servers for a number of clients and keep them updated, secured and running fast.

Most of that work is on Linux and Ubuntu, and I also have years of experience with Windows Server. When I patch a server I work carefully so one fix does not break something else, and I aim to do it right the first time.

Sources

• PHP.net: security release announcement, October 21, 2026
• PHP security advisory GHSA-w8hw-w9fx-j79w, CVE-2026-109618
• PHP security advisory GHSA-6wmf-4rv5-p3rp, CVE-2026-109619
• Huntress: php2shell, leaked critical PHP vulnerabilities
• Patchstack: major security alert for PHP
• BleepingComputer: ransomware exploits PHP flaw CVE-2024-4577
• W3Techs: usage statistics of PHP for websites

This article reflects what was known on October 22, 2026 and will be updated as more details are confirmed.