Critical PHP Vulnerability (PHP2Shell): What Your Website Needs Now

Two critical PHP vulnerabilities, nicknamed PHP2Shell, were patched on 21 October 2026, and attackers started probing for them before the fixes were even released. PHP is the software behind most business websites, including WordPress, Drupal, Joomla and Magento, so this PHP vulnerability touches a huge number of sites. The fix has to happen on the web server, not inside WordPress. This guide explains what happened, what it means for your business and what to do today, in plain English.

Last updated 23 October 2026. This story is moving quickly, so details may change.

What happened

PHP2Shell is the name security researchers gave to two bugs in the PHP interpreter, the engine that runs PHP websites. Researchers from Calif and Wiz reported them to the PHP team in August, and a coordinated release was planned. That plan broke on 20 October 2026, when details leaked online ahead of the agreed date.

• 17 October: Amazon later reported its first exploitation attempt, four days before the flaws were made public.
• 20 October: PHP gave advance notice of an emergency release. The Australian Signals Directorate (ASD) issued an unusual pre-patch alert, and CERT-EU published its own advisory.
• 21 October: PHP released the fixes. Several security companies reported attackers already probing for the flaws, and Cloudflare switched on emergency protection rules for sites behind it.
• Since then: proof-of-concept code is circulating, and Amazon, watchTowr and Cloudflare have all reported attack attempts. CISA’s alert calls for immediate patching. As at 22 October neither flaw was on its Known Exploited Vulnerabilities list, but New Zealand’s NCSC is aware of reports of active exploitation.

The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619, and PHP rates both 9.2 out of 10 for severity. In plain terms, the first lets a specially crafted upload request corrupt the server’s memory when PHP runs out of memory. The second leaves behind a stale pointer that a later request can abuse. Either one can let an attacker run their own code on your server without logging in.

What it means for your website

These flaws are in PHP itself, not in WordPress or any one plugin. That matters for two reasons.

• Updating WordPress and your plugins does not fix it. Only a patched PHP does, and PHP is normally controlled by your web host or whoever manages your server.
• It affects the common ways PHP is run. PHP lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers Apache with mod_php the highest risk, because an attack can land before any of your website’s own code runs.

The researchers demonstrated attacks with no login against default installs of WordPress, Drupal and Joomla. If an attacker gets in, they run code with the same permissions as your website. That can mean a hidden backdoor, a defaced site, spam or phishing sent from your domain, malware served to your visitors, or theft of anything the site can reach, such as enquiries, order details and database passwords. Researchers also showed the flaws can be used to read memory from the PHP process, which can hold passwords, tokens and API keys.

Which PHP versions are safe

PHP released fixes for the four versions it still supports.

The version number is not the whole story. Hosting companies and Linux vendors received the patches in advance and sometimes fix an older number without changing the label, so a host showing an older version may still be protected. That is why the first thing to do is ask.

Hosting vendors have moved quickly. cPanel and Plesk have released fixed PHP builds (cPanel’s include backports for PHP 7.4, 8.0 and 8.1), and Debian, Red Hat, Ubuntu and AlmaLinux have fixed packages out, including for some older PHP versions. Your host still has to install them and restart PHP.

What to do today

1. Find out which PHP version your site runs. In WordPress, go to Tools, then Site Health, then the Info tab, then Server. If you are not sure, your web host or IT provider can tell you.
2. Ask your host or IT provider one direct question: “Has our PHP been patched for CVE-2026-109618 and CVE-2026-109619, and has PHP been restarted since?” A patch does not take effect until PHP restarts.
3. If you run the server yourself, update PHP now. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your Linux vendor’s patched package, then restart PHP or the web server. This is an emergency update, so do not wait for the next maintenance window.
4. If you are on PHP 8.1 or older, plan the move. Those versions no longer get normal updates. A vendor fix may cover you for now, but the site should move to a supported PHP version, and it is worth checking your theme and plugins are ready first.
5. Add a safety net while you wait. A web application firewall can block known attack patterns. Cloudflare has emergency rules for the known exploits, including on its free plan, but it calls them a stopgap and they only cover traffic that passes through Cloudflare.
6. Make sure you have a clean backup. Keep a recent copy of your website and database somewhere other than the web server, so you can recover quickly if anything goes wrong.

For IT teams who cannot patch straight away

PHP and several security vendors have published temporary measures. They reduce the risk on specific attack paths, and PHP is clear that updating is the only complete fix.

• Turn off session upload progress with session.upload_progress.enabled = 0. This closes the confirmed session attack path only.
• On PHP 8.5, set fatal_error_backtraces = 0. This closes the confirmed backtrace path only.
• For the out-of-memory flaw, PHP suggests setting memory_limit = -1 in the server or pool configuration. That removes PHP’s own cap, so keep other limits in place (PHP recommends post_max_size of 8M, or 32M where uploads are needed) and watch server memory.
• If the site does not need file uploads, block multipart requests at the web server before they reach PHP.
• PHP also ships inside some control panels, firewalls and appliances, so check each vendor. For example, Palo Alto Networks lists all PAN-OS and Panorama versions as affected and, as at 22 October, had no fixed release. It advises limiting management access to trusted internal addresses.

Treat all of these as stopgaps. Set them in the main PHP or pool configuration, not through .user.ini, .htaccess or ini_set(), which can be too late in the request, and restart every worker afterwards.

Signs your site may have been hit

Security teams suggest looking for the following, especially on any server that was unpatched on 20 and 21 October:

• Unusual upload requests followed by memory-limit errors or repeated HTTP 500 errors.
• Oversized or malformed PHPSESSID cookies in the web server logs.
• PHP workers restarting for no clear reason.
• PHP files you do not recognise, especially in upload folders, or core files that have changed.
• New administrator accounts in WordPress that nobody created.
• The web server launching shells or download tools.

An empty log is not proof that you are safe. If anything looks wrong, patch first, then restore from a clean backup and change your passwords, API keys and database credentials. Our virus and malware removal team can help with the clean-up.

Also this week: a separate WordPress problem

Separate from PHP, WordPress owners are dealing with another live problem. Security firm Patchstack reports that an attacker holding valid UpdraftCentral dashboard keys has been installing backdoor plugins on connected sites since 18 October. It is a stolen-key problem rather than a software bug, and as of 19 October there was no vendor fix. Patchstack’s advice is to delete your UpdraftCentral keys, and reports say your scheduled backups keep running without them. If you use UpdraftPlus, check your Plugins list for anything you do not recognise, and check the vendor’s latest advice because this one is still developing.

Questions we get asked

Is this a WordPress problem?

No. The flaws are in PHP, which WordPress and many other systems run on. WordPress sites are exposed only because they depend on a vulnerable PHP underneath, which is why updating WordPress alone does not help.

My host says they have patched. Do I need to do anything?

Ask them to confirm that PHP was restarted after the patch and that your site runs on the patched version. Then keep your own house in order: update your plugins and theme, keep a clean backup, and watch for the warning signs above.

Should I take my website offline?

If your host has patched, no. If it has not, or you are on PHP 8.1 or older, it is a real option. CISA’s alert says organisations that cannot update straight away, or that run PHP 8.1 or older, should take PHP-based systems offline until they are patched or upgraded, and CERT-EU suggests isolating internet-facing applications from public networks until the fix is in. For a simple brochure site, a short outage usually costs less than a compromise. For a site that earns money, confirm your patch status first, apply temporary protection if you are waiting on a fix, and call us so we can help you decide.

How do I know the update is installed?

The PHP version shown in WordPress Site Health is a good first check. Some hosts fix the flaw without changing the version number, so ask your host or IT provider to confirm in writing.

Related reading

• Cyber Security Action Month 2026: Take a Second to Protect Your Business
• Web Hosting and Domains
• Web Design and SEO
• Disaster Recovery and Continuity

Sources: PHP security advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp; PHP release announcement, 21 October 2026; Rapid7; iTnews; SecurityWeek; Patchstack on PHP; Patchstack on UpdraftCentral; CERT-EU advisory 2026-018; CISA alert; Amazon threat intelligence; New Zealand NCSC; cPanel EasyApache changelog; Greenbone.