PHP2Shell: what the October 2026 PHP vulnerabilities mean for your website
Two critical PHP flaws let an attacker run code on a web server without logging in, and they are now being exploited. Which sites are exposed, what to update, and what to do if you cannot update today.
On 21 October 2026 the PHP project released emergency security updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now widely called PHP2Shell. Both let an attacker who is not logged in run code on the server. Five days later, the US cybersecurity agency CISA added both to its catalogue of vulnerabilities known to be exploited. If your website runs on PHP, and that includes every WordPress and WooCommerce site, this is the week to check it.
What the two flaws are
- CVE-2026-109618 is memory corruption in the way PHP handles running out of memory while it reads a request. A crafted upload request can leave half-built data behind that PHP then trusts. On Apache with mod_php, it can be triggered before your application's own code even runs.
- CVE-2026-109619 is a use-after-free. PHP worker processes are reused between requests, and state left over from one request can point to memory that has already been freed, which a later request can then use.
Both are rated 9.2 out of 10 on the CVSS 4.0 scale. Early reports gave them a 10.0, which the PHP Foundation has since corrected.
Who is affected
Every PHP installation that serves web requests: PHP-FPM, Apache with mod_php (the highest risk), php-cgi, FrankenPHP and LiteSpeed. The vulnerable code goes back to PHP 5.4, so old servers are affected too. Palo Alto Networks counts more than 22 million exposed instances that are potentially vulnerable.
WordPress itself needs no update; the fix is in PHP. Laravel, Magento and any other PHP application are in the same position. Odoo runs on Python, so Odoo servers are not affected by these two flaws, although a WordPress site on the same server would be.
The fixed versions
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
PHP 7.4, 8.0 and 8.1 received only minimal source patches, not official releases, and anything older gets no fix from the PHP project. Some hosting panels and package providers have released their own patched builds for these versions, but the lasting answer is to move to PHP 8.2 or newer.
Is it being exploited?
Yes. Amazon's threat intelligence team reported an attempt on 17 October, four days before the fix was published, and security firms including Cloudflare and watchTowr have reported attacks since. Public proof-of-concept code exists, and Trail of Bits has confirmed working exploits against unpatched PHP 8.2 to 8.5. How reliable an attack is depends on the server, but it is no longer safe to treat this as theoretical.
What to do now
- Find your PHP version. In WordPress, go to Tools, Site Health, Info, and open the Server section. Your hosting control panel shows it too.
- Do not trust the number alone. Linux distributions and some hosts patch PHP without changing the version number. If in doubt, ask your host for written confirmation that both CVEs are fixed.
- On managed or shared hosting, your host patches PHP. Check its status page, and if you are still on PHP 8.1 or older, switch to 8.2 or newer in the control panel after testing on a staging copy.
- On your own server or VPS, nobody will patch it for you. Install the updated packages, then restart every PHP worker: a running process keeps the old code until it restarts.
- Take a backup before any PHP upgrade, and afterwards check your checkout, forms and login pages. Older plugins and themes can break on newer PHP.
If you cannot update today
These settings reduce the risk. They do not remove it:
session.upload_progress.enabled=0closes one attack path. WordPress does not use this feature.memory_limit=-1, set at server level where applications cannot override it, narrows CVE-2026-109618, provided upload size limits stay low.- On PHP 8.5, also set
fatal_error_backtraces=0. - Restart PHP after any change. A web application firewall, such as Cloudflare's rules for these CVEs, helps as a stopgap, but only for traffic that actually passes through it.
Two more things to watch
On 23 October, PHP disclosed a separate flaw, CVE-2026-115560, in session upload progress. It only affects applications that change the session serialiser while running, and the 21 October releases do not fix it. As of 26 October there was no patch, and the same setting, session.upload_progress.enabled=0, is the recommended defence until one ships.
PHP 8.4.27 and 8.5.12 can also crash some applications that use the SimpleXML extension. The cause is a separate bug fix, not the security patches; a correction is on its way. If your site starts failing after the update, this is worth checking before you roll back.
Check for signs of a break-in
If your server was unpatched and reachable from the internet, look for commands started by the web server user, new cron jobs, unfamiliar SSH keys, new administrator accounts in WordPress, and unexpected PHP files in upload or temporary folders. If you find any of these, treat the server as compromised: restore from a clean backup and change every password and key it held.
If we built or look after your website and you would like us to check its PHP version and settings, write to us and we will confirm it in writing.
Comments