Critical PHP Vulnerability (October 2026): Attackers Can Take Over Your Website With One Request. Here’s What to Do Now

Last updated 22 October 2026. We’ll update this page as new patches, exploits and advisories are released.

This PHP vulnerability, nicknamed PHP2Shell, is one of the most serious security problems for websites in years. It’s rated 9.2 out of 10, it sits inside PHP itself rather than in any plugin or theme, and it affects every PHP version released in the last decade.

This guide explains in plain English what happened, whether you’re at risk, how to check in two minutes, and the 7 urgent steps to take today.

Is the PHP vulnerability fixed?

Yes, but only if your server has been updated. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. Older versions (8.1, 8.0 and 7.4) are no longer supported by PHP and only received limited fixes for people who build PHP themselves, so they stay vulnerable unless your hosting provider or Linux vendor has patched them.

The fix doesn’t install itself on your website. Your server has to be updated and PHP restarted. Updating WordPress or your plugins won’t fix it.

What happened, in simple terms

PHP is the programming language that runs most of the web, including WordPress, WooCommerce, Drupal, Joomla, Magento and countless custom business systems. When someone visits your site, PHP on your server handles the request.

Researchers at the cloud security company Wiz found two flaws deep inside PHP’s core:

• CVE-2026-109618: when PHP runs out of memory while handling a request, it can be left with half-prepared data that it then treats as valid.
• CVE-2026-109619: data left over from one visitor’s request can still be used by the next request after its memory has been freed.

Both are rated 9.2 (critical). Chained the right way, a single crafted request can let an attacker run their own code on your server, before your website’s own code even starts. In practical terms, that can mean:

• stealing customer data, passwords and payment details;
• installing malware, spam pages or redirects to scam sites;
• taking your site offline or holding it to ransom; and
• using your server to attack other businesses.

Wiz reported the bugs to PHP’s security team on 24 August 2026, and the fixes were published on 21 October. Amazon’s threat intelligence team says its honeypot recorded an exploitation attempt on 17 October, four days before public disclosure. Rapid7 expects a working exploit to become public soon and attacks to follow.

What the PHP vulnerability affects (it’s not just websites)

Because the flaw is in PHP itself, it doesn’t matter how well your own website or software is built. Anything running on PHP that handles web requests is exposed until it’s patched:

• Websites built with WordPress, Drupal, Joomla and other PHP platforms;
• Online shops on WooCommerce, Magento or Adobe Commerce;
• Custom business software built in PHP, such as Laravel or CodeIgniter systems for ERP, CRM, bookings, schools, HR and customer portals;
• Mobile app backends and APIs written in PHP (the app on the phone is fine, but its server isn’t);
• Intranets and admin dashboards; and
• Some network and security devices. Palo Alto Networks says all PAN-OS and Panorama versions are affected, and Cisco and Fortinet are investigating dozens of products.

All the common server setups are affected, including PHP-FPM, Apache with mod_php, LiteSpeed, php-cgi and FrankenPHP. Researchers demonstrated the most direct attack against Apache with mod_php.

Not affected: software built entirely on other technologies, such as Node.js, Java, .NET or Python, and static websites with no PHP.

Are you at risk? Check in 2 minutes

Step 1: Find your PHP version

• WordPress: go to Tools → Site Health → Info and open the Server section.
• cPanel: open Select PHP Version or MultiPHP Manager.
• Your own server: run php -v, and check the version your web server actually uses, which can differ.

Be careful: Linux distributions and hosting providers often patch PHP without changing the visible version number. If you’re unsure, ask your host directly.

Step 2: Work out who’s responsible for patching

Your hosting	Who patches PHP	What you should do
Managed WordPress hosting	Your host	Check their status page or email, and confirm in writing that the 21 October fix is applied.
Shared hosting (cPanel and similar)	Your host, for everyone on the server	Open a support ticket and ask whether your PHP version includes the fix. Some hosts are still rolling it out.
VPS, cloud or dedicated server	You or your developer	Update PHP and restart it today. Nobody else will do it for you.
Custom software or app backend	Whoever manages the server	Ask your developer or IT provider to confirm every server is patched.

If you have a VPS, a cloud server or custom software, you’re in the group that needs to act today.

Vulnerable and fixed PHP versions

PHP version	Status	Safe version
8.5	VULNERABLE below 8.5.12	8.5.12 or later
8.4	VULNERABLE below 8.4.27	8.4.27 or later
8.3	VULNERABLE below 8.3.36	8.3.36 or later
8.2	VULNERABLE below 8.2.35	8.2.35 or later
8.1, 8.0, 7.4	END OF LIFE: vulnerable unless your host or vendor has patched it	Upgrade to 8.3 or later
7.3 and older	END OF LIFE: vulnerable	Upgrade urgently

7 urgent steps to take today

1. Confirm the patch, in writing

Ask your host or developer a simple question: “Has the PHP security release of 21 October 2026 been applied to every server running our website and systems, and has PHP been restarted?” Get a yes or no, not a general reassurance.

2. Update PHP and restart it

If you manage the server, install the fixed version from your operating system’s packages or your vendor, then restart PHP-FPM, Apache or LiteSpeed so every worker runs the new code. A patch that’s installed but not loaded doesn’t protect you.

3. Take a full backup first

Back up your files and database before any update, and store the copy away from the server. If something breaks, or if the site has already been tampered with, you’ll need a clean restore point.

4. Turn on a web application firewall

Cloudflare has released firewall rules for the known attack methods, available on all plans including the free one. On paid plans, make sure managed rules are set to block, not just log. A firewall buys time, but it’s not a substitute for patching.

5. Apply temporary server settings if you can’t patch yet

For server administrators, Rapid7 lists interim measures that reduce, but don’t remove, the risk:

• set session.upload_progress.enabled=0 in php.ini or the FPM pool, then restart (WordPress doesn’t use this feature);
• set memory_limit=-1 at server level so applications can’t override it, then restart;
• on PHP 8.5, set fatal_error_backtraces=0;
• lower post_max_size to 8M, or 32M if you need uploads, and keep upload_max_filesize below it; and
• block multipart form uploads at the firewall if your application doesn’t use them.

Hiding errors doesn’t help, and a clean error log doesn’t prove you’re safe. The UK’s National Cyber Security Centre advises taking systems offline if they can’t be fixed right away.

6. Check every system, not just the main website

Staging sites, old microsites, landing pages, client portals, booking systems and app backends are often forgotten. Any one of them can give an attacker a way in, especially if they share a server with your main site.

7. Update themes and plugins, and plan your PHP upgrade

Many sites stay on old PHP because an outdated theme or plugin won’t work on newer versions. Update or replace them now, so you can move to a supported PHP version and stay on it.

If you’re on PHP 8.1, 8.0 or 7.4

PHP 8.1 reached end of life at the end of 2025, and 8.0 and 7.4 even earlier. That means no routine security fixes from PHP, ever again. This PHP vulnerability is a clear warning: the next serious flaw may not get any fix at all for these versions.

If your host has backported the fix, you may be protected for now, but you should still upgrade:

1. Create a staging copy of your site or system.
2. Switch staging to PHP 8.3 and test every important page, form, checkout and integration.
3. Fix or replace anything that breaks, usually old plugins, themes or custom code.
4. Back up the live site, then switch it to the new version at a quiet time.
5. Monitor error logs and key pages for a few days.

For custom software, your developer will need to check code and libraries for compatibility. This usually takes days, not months, and it’s far cheaper than recovering from a breach. Our earlier article on the 2026 WordPress security crisis covers other ways sites are being attacked this year.

Signs your site may already be compromised

Researchers suggest watching your server logs for:

• unusual multipart (file upload) requests followed by memory limit errors or repeated HTTP 500 errors;
• unusually large or malformed PHPSESSID cookies; and
• PHP worker processes restarting or crashing for no clear reason.

Also look out for the usual signs of a hacked website:

• new admin users you didn’t create;
• unknown files in your website folders, especially PHP files in upload directories;
• redirects to spam, gambling or scam sites, sometimes only on mobile or from Google;
• strange pages appearing in Google search results for your domain;
• sudden spikes in server CPU or outgoing email; and
• warnings from your host, Google Search Console or your browser.

If you see any of these, don’t just patch and move on. Take a clean backup of the evidence, then have the site professionally checked and cleaned, and change all passwords and API keys.

Why this PHP vulnerability is different: AI and decade-old bugs

These flaws had been hiding in PHP for more than ten years, affecting versions back to PHP 5.4. Wiz says frontier AI models helped with discovery, exploit development and patch testing, and greatly reduced the effort needed to turn very complex bugs into a working attack across different PHP versions and setups.

The lesson for businesses is simple: the time between a flaw being announced and attackers using it is shrinking fast. Patching “sometime this month” is no longer good enough. You need someone responsible for updates, monitoring and backups, all the time.

If customer data is exposed: Sri Lanka and Australia

A PHP vulnerability that lets attackers into your server can quickly become a data breach, and that brings legal duties as well as technical ones.

• Sri Lanka: the core duties of the Personal Data Protection Act apply from 1 January 2027, including keeping personal data secure. Now is the time to show you take security seriously. Our PDPA website compliance checklist explains what your website needs.
• Australia: organisations covered by the Privacy Act must notify affected people and the Office of the Australian Information Commissioner when a data breach is likely to cause serious harm, under the Notifiable Data Breaches scheme.

Either way, keep a simple record of what you did and when: when you learned about the flaw, when you contacted your host, when the patch was confirmed, and any checks you ran. If something does go wrong, that record shows you acted quickly and responsibly.

A 5-minute checklist for business owners

1. List every website and system your business runs on PHP.
2. Send your host or developer the “has the 21 October fix been applied?” question for each one.
3. Confirm you have a recent backup stored off the server.
4. Check your firewall or Cloudflare settings are blocking, not just logging.
5. Book the PHP upgrade for any site on 8.1, 8.0 or 7.4.

How Microweb Global can help

We build and look after websites, online shops, custom software and app backends for businesses in Sri Lanka and Australia. Right now we can:

• check your PHP version and confirm whether your site and systems are patched;
• update PHP on servers you manage, with backups and testing;
• upgrade sites stuck on PHP 8.1, 8.0 or 7.4, and fix incompatible plugins, themes and code;
• scan for signs of compromise and clean infected sites; and
• set up firewalls, monitoring and ongoing maintenance so you’re covered next time.

Learn more about our website development and custom software development services.

PHP vulnerability: frequently asked questions

Not sure if you’re safe? Get a free emergency check

Send us your website address. We’ll check which PHP version you’re running, whether the fix is in place, and tell you exactly what to do next, free of charge.

Get my free PHP vulnerability check →  |  Australian businesses: contact us here →

Sources

• PHP 8 ChangeLog, The PHP Group
• PHP2Shell: critical RCE vulnerabilities in PHP, Wiz Research
• CVE-2026-109618 and CVE-2026-109619, Rapid7
• PHP Group security advisory AV26-764, Canadian Centre for Cyber Security
• PHP2Shell: critical PHP vulnerabilities patched, Help Net Security
• How to find, mitigate and patch PHP2Shell, Qualys
• What WordPress site owners need to do, Codeable