A critical flaw in PHP itself puts UK business websites on WordPress, Magento, Laravel, Drupal and custom PHP at risk. Here is what happened, what it means for your legal duties, and how to fix it.
Critical · CVSS 9.2Disclosed: 21 October 2026Last updated: 23 October 2026
Summary: Two memory corruption flaws in the PHP engine allow an attacker on the internet to run code on your server with a single crafted web request, with no login required. Active exploitation has been reported. Updating the PHP runtime is the only complete fix.
What this means for UK businesses
If your company website, online shop, client portal or intranet runs on PHP, you are likely affected, even if the site itself is fully up to date. That covers most WordPress and WooCommerce sites, Magento and Adobe Commerce stores, Laravel and Drupal applications, and any bespoke PHP system a developer built for you.
UK GDPR: if this flaw is used to access personal data and the breach is likely to put people at risk, you must tell the ICO without undue delay and within 72 hours of becoming aware of it. Breaches you decide not to report must still be recorded internally.
Cyber Essentials: the scheme requires critical and high-risk updates (CVSS 7.0 or above) to be applied within 14 days of release, and software that is no longer supported, such as PHP 8.1 and older, is an automatic fail. A CVSS 9.2 flaw on an in-scope PHP server is squarely covered.
Cyber insurance: insurers increasingly expect known critical vulnerabilities to be patched promptly, and an unpatched server can complicate a claim.
Customer trust: a compromised site can be used to steal card details, send spam from your domain or host malware, which damages your reputation and search ranking.
What has been disclosed
The flaws are tracked as CVE-2026-109618 and CVE-2026-109619 and are collectively nicknamed PHP2Shell. Both carry a CVSS score of 9.2.
CVE-2026-109618: an out-of-memory condition during early request handling, for example while parsing a file upload, can leave internal request data half-initialised. Clean-up code then frees invalid memory, which can be turned into code execution.
CVE-2026-109619: request-specific state can remain referenced after it has been freed. A later request handled by the same PHP worker can then use stale memory.
Because the problem sits in PHP rather than in your application, it triggers before WordPress, Laravel or any plugin code runs. A fully patched application on an unpatched PHP runtime is still exposed.
The flaw triggers inside PHP while the request is still being parsed, before WordPress, Laravel or any security plugin gets a chance to run.
Which versions are affected
All PHP versions from 5.4 up to and including 8.5.11 are affected. Fixes have been released for the supported branches:
Branch
Update to at least
PHP 8.5
8.5.12
PHP 8.4
8.4.27
PHP 8.3
8.3.36
PHP 8.2
8.2.35
PHP 8.1 and older
End of life. Upgrade to a supported branch, or use a vendor-backported security package.
What to do first
Find every PHP site you run. Include old brochure sites, staging servers, intranets and anything a supplier hosts for you.
Update the PHP runtime on each server to a patched build, then restart PHP-FPM or the web server so the new version is actually in use.
Retire end-of-life PHP. If a site depends on PHP 8.1 or older, move it to a supported branch or place it behind a vendor-backported package while you plan the upgrade.
If you cannot patch today, put the site behind a web application firewall with rules for malformed multipart uploads, restrict upload endpoints, or take the site offline. These are stop-gaps only. Changing php.ini values does not remove the risk.
Check for compromise. Look for unfamiliar PHP files in upload and cache folders, new administrator accounts, changed files with recent timestamps and unusual outbound traffic. Patching does not remove a backdoor that was planted earlier.
Patch the PHP runtime, restart services, then verify. That is the whole fix.
Mitigation by platform
The steps below assume you control the server. If a hosting company manages PHP for you, ask them to confirm in writing which patched version is live.
CMS
WordPress
The flaw is in PHP, not in WordPress, so updating WordPress core, themes or plugins does not fix it. The PHP version on the server must be updated.
Find your PHP version under Tools, Site Health, Info, Server in the dashboard.
On managed WordPress hosting, ask the host to confirm in writing that they have deployed the patched PHP build. On a VPS or dedicated server, follow the Linux or control panel steps below.
If you are on PHP 8.1 or older, move to PHP 8.3 or 8.4 and test plugins on a staging copy first.
Keep a recent offsite backup and check the uploads folder and wp-config.php for files you do not recognise.
E-commerce
Magento and Adobe Commerce
Magento stores are a high-value target. Treat this as an emergency change.
Check which PHP versions your Magento release supports, then update to the highest supported patched branch (8.2, 8.3 or 8.4).
If your Magento version only supports an end-of-life PHP branch, use a vendor-backported package (see Linux below) and plan an upgrade of Magento itself.
Restart PHP-FPM after updating and flush the opcode cache.
Review recent orders, admin users and checkout templates for signs of tampering or card skimming scripts.
Framework
Laravel
Run php -v on the server that serves the app, not only on your development machine.
Update PHP on the host, then restart PHP-FPM or Octane workers so long-running processes pick up the new binary.
For Docker or Laravel Sail, pull a base image that includes a patched PHP version, rebuild and redeploy.
For Forge, Vapor or other managed platforms, check the provider status page and trigger a redeploy where required.
Rotate APP_KEY, database and API credentials if you suspect the server was exposed before patching.
CMS
Drupal
Open Reports, Status report in the Drupal admin area to see the PHP version in use.
Confirm the patched PHP branch is supported by your Drupal core version (Drupal 10 and 11 support current PHP 8.x branches).
Update PHP at server level, restart the web server or PHP-FPM, then clear caches.
Review the watchdog log and the list of administrator accounts for anything unexpected.
Control panels
Plesk and cPanel hosting
Plesk: apply all pending updates under Tools and Settings, Updates, and check that each subscription is using a PHP handler from the updated build.
cPanel and WHM: run the EasyApache 4 and system package updates, then confirm each ea-php package is on a patched build. Run the cPanel upcp update if prompted.
Check every domain, not just the main one. Domains pinned to an old PHP version stay exposed.
Shared hosting customers should open a ticket asking the host to confirm the patched version is live on their server.
Infrastructure
Linux servers and containers
Ubuntu and Debian: sudo apt update, then sudo apt upgrade for the php packages, then restart PHP-FPM and your web server.
RHEL, AlmaLinux and Rocky: sudo dnf update php* and restart services. Remi and similar repositories publish patched builds.
Distributions often backport the fix without changing the version number. Check the package changelog for CVE-2026-109618 and CVE-2026-109619 rather than trusting php -v alone.
Containers: rebuild images from an updated base, redeploy every service that bundles PHP, and remove old images from your registry.
Frequently asked questions
What is the PHP2Shell vulnerability?
PHP2Shell is the name given to two critical flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2. They allow an attacker on the internet to run code on a web server with a single crafted request and no login.
Is my WordPress website affected?
Yes, if the server it runs on uses an unpatched PHP version. The flaw is in PHP, not in WordPress, so updating WordPress, themes or plugins does not fix it. The PHP version on the hosting server must be updated.
Which PHP versions fix the problem?
Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. PHP 8.1 and older are end of life and receive no official fix, so move to a supported version or use a vendor-backported security package.
Do I have to report this to the ICO?
Patching is not itself reportable. But if the flaw was used to access personal data and the breach is likely to result in a risk to individuals, UK GDPR requires you to notify the ICO without undue delay and within 72 hours of becoming aware of it. The clock starts when you become aware, not when your investigation finishes. Patch fast and check for signs of compromise so you know where you stand.
How does this affect Cyber Essentials?
Cyber Essentials requires updates that fix critical or high-risk vulnerabilities (CVSS 7.0 or above) to be applied within 14 days of release. These PHP flaws are rated 9.2, so an in-scope server left unpatched can put your certification at risk. Software that is no longer supported, such as PHP 8.1 and older, also fails the requirement unless it is upgraded or isolated.
Can a firewall or a PHP setting protect me instead of patching?
A web application firewall can reduce exposure as a short-term measure, but changing php.ini settings does not remove the risk. Updating the PHP runtime is the only complete fix.
Do not trust the version number alone
Enterprise Linux vendors and hosting panels frequently ship the fix as a backport, so the version string may look older than the numbers above while the server is protected. The reverse also applies: a container image that was built last month will still contain the old PHP until it is rebuilt. Confirm with the vendor changelog, not guesswork.
Need a hand? PurpleBox is a London managed IT and security provider. We can audit your PHP estate, patch servers, check for signs of compromise and put monitoring in place for businesses across London and the UK. Call 0207 613 1378 or .
This page is a summary for business owners and IT teams, based on public advisories from the PHP project and security vendors. Always check your own vendor advisories for the exact package versions that apply to your environment. See also our IT security service and managed IT support.
