Critical PHP Vulnerabilities (October 2026): What Website Owners Need to Do Now

On 21 October 2026 the PHP project released emergency updates for two critical vulnerabilities that can let an attacker run their own code on a web server without logging in. If your website runs on PHP, and most business websites do, it needs to be on PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or on a vendor build that includes the fix. If it runs on PHP 8.1 or older, this is the moment to plan your way off it.

The flaws, tracked as CVE-2026-109618 and CVE-2026-109619, are each rated 9.2 out of 10 for severity. Governments and national cyber security agencies, including the UK’s National Cyber Security Centre (NCSC), told organisations that can’t update quickly to consider taking their websites offline until they can. Some public bodies did exactly that.

This guide explains what happened in plain English, how to tell whether your website is affected, what to do now and what we recommend for businesses still running older versions of PHP. It is based on the official advisories and on our own work updating the business websites we look after on the day of the release.

What Happened, in Brief

The PHP Foundation has been unusually open about the background. An earlier version of the problem was spotted during a security audit in 2024, but no realistic way to exploit it was known, and the fix touched such a central part of PHP that work on it repeatedly stalled. The 2026 reports showed it could be exploited remotely, and it became the security team’s top priority.

What the Two Vulnerabilities Actually Do

Both flaws are in parts of PHP that nearly every web request passes through, which is why they matter so much.

• CVE-2026-109618 (out-of-memory corruption). If a request hits PHP’s memory limit at exactly the wrong moment, PHP can leave half-built data behind and later treat it as valid. On Apache with mod_php, an attacker can trigger this before any of your website’s own code runs, with default settings. It was also shown to work on PHP-FPM, the setup most modern hosting uses, through code paths in real applications.
• CVE-2026-109619 (stale state). A fatal error at the wrong point can leave PHP pointing at memory that belonged to an earlier visitor’s request. A later request handled by the same PHP worker can then use that memory. Researchers demonstrated remote code execution against a real application.

“Remote code execution” is the most serious class of web vulnerability. It means an attacker can make your server run their commands: reading your database, planting malware or a backdoor, sending spam or using your server to attack others. The US National Security Agency warned that flaws like these “often provide a direct path to the server’s file system or database”.

"This one is different from the usual security update. It doesn't depend on a weak password, an old plugin or a mistake on your website. It's in PHP itself, which sits underneath WordPress, WooCommerce, Magento, Laravel and most of the other platforms business websites are built on." Giedrius Kudzinskas, founder of Rubik Digital

Is Your Website Affected?

If your website runs on PHP and hasn’t been updated since 21 October 2026, assume it is affected. PHP runs WordPress, WooCommerce, Drupal, Joomla, Magento, Concrete CMS, Craft CMS, Laravel and Symfony applications, as well as many hosting control panels. The PHP project says every installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

Websites built entirely on hosted platforms such as Shopify, Squarespace or Wix are managed by those providers, so there is nothing for you to update on PHP. The same goes for purely static websites. But if any part of your online presence runs on PHP, such as a WordPress blog on a subdomain, a booking system or an old microsite, it needs checking too.

What each PHP version needs

How to check your PHP version

• WordPress: go to Tools → Site Health → Info → Server. The PHP version is listed there.
• Hosting control panel: Plesk, cPanel and most managed hosts show the PHP version for each website in its hosting or PHP settings.
• Ask your host or developer: ask them two questions. Which PHP version is each of our websites running? Does it include the 21 October 2026 security fix?

The second question matters for older versions. Several hosting providers, including Plesk, released emergency builds of PHP 7.4, 8.0 and 8.1 with the fix included. These builds keep the same version number as before, so 7.4.33 is still 7.4.33. Only the build date shows whether the fix is included. Plesk’s advisory, for example, says builds made on 21 October 2026 include the fix and earlier ones don’t.

What to Do Now: A Checklist

1. Update PHP on every website. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your host’s patched build. On managed hosting this is usually done for you, but confirm it rather than assume.
2. Restart PHP everywhere. A running PHP process keeps the old, vulnerable code in memory until it restarts. Web workers usually restart when PHP is updated. Long-running background jobs, such as email queue workers and schedulers, often don’t. We found two of these still running old code after the update.
3. Find every place PHP runs. Staging copies, old campaign microsites, forgotten subdomains, helpdesks and internal tools are all just as exposed as your main website, and usually less well maintained. If nobody uses a site any more, remove it.
4. Don’t forget the control panel. Hosting panels often run their own copy of PHP, separate from your websites. Check your provider’s advisory and, until it’s patched, restrict who can reach the panel.
5. Check for signs of a break-in. Look for unfamiliar admin accounts, recently changed PHP files, files in upload folders that shouldn’t be there, unexpected scheduled tasks and unusual outgoing traffic. A good security scanner will help. If you were exposed before updating, this step matters as much as the update itself.
6. Change important passwords if in doubt. If anything looks wrong, rotate admin passwords, database passwords and API keys after cleaning up, not before.
7. Keep watching for updates. The NCSC advises monitoring for updates from third-party vendors too, including products and appliances that bundle PHP without advertising it.

If you can’t update straight away

The PHP project has published temporary measures that reduce exposure to specific attack paths. It is clear that these don’t make a website safe; only updating does. They include:

• turning off PHP’s session upload progress feature (session.upload_progress.enabled = 0) at server level and restarting every PHP worker;
• lowering the maximum request size (post_max_size), especially on sites that don’t accept file uploads;
• fixing errors and timeouts that visitors can trigger, such as failures in upload or import processing.

These changes need care, because some of them can break legitimate features. If your website can’t be updated within a day or two, follow the NCSC’s advice and consider taking it offline until it can.

The Bigger Problem: Websites Still on Old PHP

The emergency builds for PHP 7.4, 8.0 and 8.1 are good news, but they shouldn’t reassure anyone running those versions. The PHP security team made an exception for these two flaws because they were so severe. It doesn’t mean old versions are supported again.

PHP 7.4 stopped receiving official security updates in November 2022. A website running it today may have been missing security fixes for almost four years, and the next serious flaw may not get an emergency backport at all. For PHP 7.3 and older, even Plesk recommends paid extended-support services instead.

If your website is on PHP 8.1 or older, you have three realistic options:

Why Upgrading PHP Isn’t Just Flicking a Switch

Most hosting panels let you change a website’s PHP version from a dropdown menu. On an older website, doing that on the live site is a good way to take it down. That’s because PHP 8 is stricter than PHP 7:

• Things that used to be quiet notices are now warnings. Using a variable that hasn’t been set, or reading a missing value from a form or web address, used to pass silently. Many content management systems turn PHP 8 warnings into an error page.
• Old syntax has been removed. Code written years ago, for example using curly braces to read characters from a string, no longer runs at all.
• The CMS itself may not support the newer PHP. An old version of WordPress, Concrete CMS, Magento or Laravel may need updating before it will run on PHP 8.4 or 8.5, and that update may in turn need theme and plugin changes.

A real example: an old CMS website moved to PHP 8.4

On the day of the release we moved a business website from PHP 7.4 to 8.4. It ran an older version of Concrete CMS with a custom theme and several custom add-ons. Switching PHP version on the live site immediately showed an error page, so we switched it straight back and worked on a private copy on the same server instead. That copy showed:

• around 85 places in the theme and custom add-ons that needed small fixes, almost all of them reading values that might not exist;
• one page that had been broken for years, because its template pointed at a file that no longer existed;
• a few admin screens that only worked properly once the CMS itself was updated to a version that supports PHP 8.4.

We fixed the code, then tested every public page and every admin screen on the copy. After that we updated the CMS on the copy and tested again. Then we made the same changes on the live site. The site was unavailable for about 15 seconds.

"The upgrade itself took seconds. Everything before it, the backups, the test copy and checking every page, is what made those seconds safe. Changing PHP on a live website and hoping for the best is how a security update turns into an outage." Giedrius Kudzinskas, founder of Rubik Digital

What We Found While Checking Websites

Checking websites after an event like this often turns up older problems. Two things we came across are worth checking on any website, whatever version of PHP it runs:

• Leftover developer shortcuts. Some older website themes contained test code that logged a visitor straight in as the main administrator, with no password, if a particular word was added to the web address. They had been left behind after development, sometimes years earlier. We removed them. If your website was built or changed by several developers over the years, have the code reviewed for this kind of thing.
• Error pages that show too much. Some websites showed visitors full technical error details, including file paths on the server, whenever something went wrong. That helps developers, but it also helps attackers. A live website should show a plain error page and keep the details in its logs.

Our Recommendations

1. Today: confirm that every website and PHP-based tool you own is on a fixed PHP version or a patched vendor build, and that background PHP jobs have restarted.
2. This week: check for signs of compromise, remove websites nobody uses, and make sure live websites don’t show technical error details to visitors.
3. This month: list every website still on PHP 8.2 or older. Note that 8.2 reaches end of life on 31 December 2026.
4. This quarter: for each website on old PHP, decide whether to upgrade, rebuild or retire it, and set a date. Paid extended support is fine as a bridge while you do that.
5. Ongoing: make sure someone is responsible for applying security updates within days, not months. This event showed how little warning there can be.

If you don’t know what your websites run on or who would apply an emergency update, that’s the first thing to fix. An independent website audit will tell you what you have, what is out of date and what to do first. And if you’re weighing up an upgrade against a rebuild, our guides to website maintenance costs and website development costs in the UK will help you compare.

Sources

• PHP security advisory, 21 October 2026 (php.net)
• The PHP Foundation: Today’s PHP Security Release, and How We’re Strengthening PHP Security
• Plesk advisory: CVE-2026-109618 and CVE-2026-109619
• BBC News: Websites taken down worldwide as critical cyber-security update issued