PHP Fix: How to Patch the Critical PHP2Shell Flaw on Your Website

Last updated: 22 October 2026. This is a fast-moving story; we will update this page as hosts and agencies publish more.

If you have heard that a PHP weakness is making organisations take their websites offline, it is true, and the PHP fix is already out. 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.^[1] This plain-English guide explains what PHP is, what the flaw does, whether your site is affected and how to apply the PHP fix or get your host to confirm it. Everything here is accurate as of 22 October 2026.

What is PHP, and why does this affect so many websites?

PHP is a programming language that runs on web servers. When someone visits a page, PHP builds it on the fly, fetching data from a database, handling forms and logins, then sending the finished page to the browser.^[3] WordPress, WooCommerce, Drupal, Joomla, Magento and many other systems are written in PHP. That is why a flaw in PHP itself matters so much: it is not one plugin or one website, it is the engine underneath a large share of the web.

You do not normally see PHP. On a WordPress site it is part of your hosting, like the plumbing in a rented shop: you can redecorate (update WordPress and plugins) yourself, but the plumbing belongs to whoever runs the building.

What is the PHP2Shell vulnerability (CVE-2026-109618 and CVE-2026-109619)?

There are two related flaws, both rated critical with a CVSS v4.0 score of 9.2 out of 10.^[2][4] Both concern how PHP tidies up memory when a request goes wrong.

• CVE-2026-109618 (out-of-memory corruption): if a request makes PHP hit its memory limit at exactly the wrong moment, PHP can be left with half-prepared data that its clean-up routine then treats as real.^[2]
• CVE-2026-109619 (stale global state): some information from one request can survive after its memory has been released, and a later request handled by the same PHP worker can use that leftover information before it is reset.^[4]

An attacker who carefully crafts web requests can turn either problem into remote code execution, which means running their own commands on your server with the same permissions as your website.^[2][4] The PHP project says the risk is highest on Apache with mod_php, where a demonstrated attack works from a single unauthenticated request before any of the website's own code runs.^[1]

What can an attacker do with the PHP vulnerability?

Once someone can run code on your web server, they can usually read what your website can read. For a small business that can mean customer names, emails and orders in the database, form submissions, and the keys your site uses for email or payment services. They could also deface the site, add hidden redirects, plant a backdoor or use your server to attack others. The NSA put it bluntly, in words reported by the BBC: these flaws "often provide a direct path to the server's file system or database".^[5]

Is the PHP flaw being exploited yet?

The honest answer, as of 22 October 2026, is that reports differ. CISA said on 21 October that it had not observed exploitation at the time it published,^[6] and the two CVEs were not in CISA's Known Exploited Vulnerabilities catalogue in the version released that day. CERT-EU noted that proofs of concept had begun to circulate and that this raises the likelihood of attacks.^[7] Cloudflare said it observed attack traffic aimed at its customers after details leaked, before the official release.^[8] Treat it as urgent either way: the details are public.

Why did websites go offline over PHP?

Because the official advice for anyone who could not patch quickly was to take PHP systems offline. The UK's NCSC told organisations that if they cannot apply the update or the temporary mitigations in time, they should consider taking the system offline until it is fixed.^[3] CISA gave similar advice for systems that cannot be updated, including those on unsupported PHP 8.1 or earlier.^[6]

The BBC reported that Finland temporarily shut down public government web services, the Dutch cyber security agency took its own website offline, and the Wikimedia Foundation took some systems down as a precaution.^[5] Some other outages had not been confirmed as linked to PHP, so not every one you hear about is this flaw. Details also leaked on social media before the planned release, which forced the PHP team to publish early.^[5]

Am I affected by the PHP vulnerability? A quick checklist

If you answer yes to the first question and have not confirmed the patch, assume you are affected.

• Does your website run on WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel or another PHP system?
• Is your PHP version lower than 8.5.12, 8.4.27, 8.3.36 or 8.2.35 on its branch?^[2]
• Are you on PHP 8.1, 8.0, 7.4 or older? These get no official PHP release.^[1]
• Do you manage your own server or VPS, rather than having a managed host do it?
• Do you run PHP tools you might forget, such as a staging site, an old microsite or a booking system?
• Do any appliances or products you use include PHP inside them? The NCSC asks organisations to check third-party products that bundle PHP too.^[3]

The PHP project says every PHP installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.^[1] Security researchers trace the affected code back many years, at least to PHP 5.4.^[8]

How do I check my PHP version?

• WordPress: log in, go to Tools > Site Health, click the Info tab and open Server. The PHP version is listed there.^[9]
• cPanel: open MultiPHP Manager or Select PHP Version to see the version for each domain.
• Plesk: go to Websites & Domains and look at PHP or Hosting settings for the domain.
• Command line: run php -v. Be aware that the web server may use a different PHP from the one on the command line, so also check the version your site reports.

A version number does not always tell the whole story: some hosts and Linux distributions backport fixes without changing it. If in doubt, ask your host whether CVE-2026-109618 and CVE-2026-109619 are fixed on your account.

How to apply the PHP fix, step by step

1. Find out who manages PHP. Managed or shared hosting: your host. A VPS or your own server: you or your developer.
2. Check your PHP version. Use WordPress Site Health, your control panel or php -v.
3. Compare it with the fixed versions. 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later, or a host package with the fix backported.
4. Take a backup. Back up files and the database first.
5. Apply the update. Ask your host to confirm it, or update through cPanel, Plesk or your package manager.
6. Restart PHP and the web server. On your own server, restart PHP-FPM, Apache or LiteSpeed.
7. Confirm it worked. Check the version again and test the site.

Managed WordPress or shared hosting

Your host updates PHP, not you. Check its status page or ask support: "Has PHP on my account been patched for CVE-2026-109618 and CVE-2026-109619?" For example, GoDaddy said on the evening of 21 October that it had patched all PHP versions on its Managed Hosting for WordPress and that customers there did not need to take action. For its cPanel and Windows web hosting, it said it had put mitigations in place while waiting for patched packages from its vendor.^[9]

cPanel or Plesk that you control

If you choose your own PHP version, make sure it has the patched release, or move to 8.2 or later if you are on 8.1 or older. On cPanel/WHM on your own VPS, install the updated PHP packages through EasyApache 4; GoDaddy reports that cPanel has also backported the fix to its PHP 7.4, 8.0 and 8.1 packages.^[9]

Your own server or VPS

Update PHP through your package manager or PHP package source, then restart PHP-FPM, Apache or LiteSpeed. PHP says Linux distributions and long-term support vendors received the patches in advance.^[1] Run php -v afterwards, check the version your site reports, and restart any long-running PHP processes.

WordPress Site Health and WordPress updates

Updating WordPress and plugins is still worth doing, but it will not fix this. WordPress's own guidance is that your host normally handles PHP updates, and that you should back up and check plugin compatibility first.^[10] Afterwards, go back to Tools > Site Health > Info > Server and check the version again.

What if I cannot update PHP straight away?

PHP has published temporary measures, but it is clear they reduce exposure and do not make a site safe; only the update is a complete fix.^[1] If you manage the server, the main ones are:

• Turn off session upload progress with session.upload_progress.enabled=0 in php.ini or the server configuration (not ini_set() or .user.ini), then restart every PHP worker.^[1]
• Set memory_limit=-1 in a way applications cannot override, and keep post_max_size low (8M if you do not need uploads, 32M if you do).^[1]
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.^[1]
• Put a web application firewall in front of the site. Cloudflare says its free and paid WAF plans have blocked known PHP2Shell attack patterns by default since 21 October, but it also says this is a stopgap and you should still patch.^[8]

Test your site afterwards, as some settings can break upload progress bars or large uploads. If none of this is possible quickly, follow the NCSC advice and consider taking the site offline until it is patched.^[3]

What should I do after applying the PHP fix?

Patching closes the door but does not tell you whether anyone came in while it was open. The NCSC recommends checking unpatched systems for signs of compromise and backdoors.^[3] In practice, for a small business site, that means:

• Check WordPress for admin accounts you do not recognise, and change admin, hosting and database passwords.
• Run a malware scan, or ask your host to.
• Rotate any API keys stored in the site, such as email, payment or shipping integrations.

Why this is also a data security story

PHP2Shell is a reminder that personal data is only as safe as the weakest place it is stored, whether a web server or an old laptop in a cupboard. Data you no longer need should be removed properly, not left on a drive that could be lost or resold. If you look after customer data on old office computers, our guide to a data wiping process for small businesses under UK GDPR covers the practical steps.

PHP fix FAQs

What is the PHP fix for CVE-2026-109618 and CVE-2026-109619?

Updating PHP itself to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, released by the PHP project on 21 October 2026. Older versions on the same branch are affected unless your host or Linux distribution has backported the fix.

How do I check my PHP version?

In WordPress, go to Tools > Site Health > Info > Server. In cPanel or Plesk, check the PHP version set for the domain. On your own server, run php -v, and check the version the website itself reports.

Is my WordPress site affected by PHP2Shell?

Probably, until the PHP it runs on is patched. The flaw is in PHP, not WordPress, themes or plugins, so updating WordPress will not fix it. Your host, or whoever manages your server, has to update PHP.

What if I am on PHP 8.1, 8.0 or 7.4?

The PHP project no longer issues official releases for 8.1 and older. It has published minimal source backports for 7.4, 8.0 and 8.1, and some hosts have backported the fix, but the safest route is a supported version such as 8.3 or 8.4.

Do I need to do anything if my site is on Shopify, Wix or Squarespace?

Generally no. On fully hosted platforms you do not install or manage PHP, so there is nothing for you to patch; the platform looks after its own servers. Check any other sites or self-hosted tools you run alongside it.

Sources

1. PHP security advisory and release announcements, php.net (21 October 2026)
2. GHSA-w8hw-w9fx-j79w, RCE via OOM corruption (CVE-2026-109618), PHP project on GitHub
3. NCSC, Critical security issue affecting PHP (21 October 2026)
4. GHSA-6wmf-4rv5-p3rp, RCE via stale global state (CVE-2026-109619), PHP project on GitHub
5. BBC News, Websites taken down worldwide as critical PHP cyber-security update issued (21 October 2026)
6. CISA, Critical Vulnerabilities in PHP Require Immediate Patching (21 October 2026)
7. CERT-EU, Security Advisory 2026-018: Critical Vulnerabilities in PHP
8. Cloudflare, Cloudflare deploys protections against php2shell vulnerability (21 October 2026)
9. GoDaddy, Important PHP security update: What website owners need to do (updated 21 October 2026)
10. WordPress.org, Get a faster, more secure website: update PHP today

This article is general information for website owners, accurate as of 22 October 2026. It is not a substitute for advice from your host, developer or security provider.