PHP2Shell: the critical PHP flaw, and what it could do to a WordPress business

On Wednesday 21 October, at 14:00 UTC (15:00 in the UK), the PHP project released emergency fixes for two critical security flaws. Researchers have nicknamed them PHP2Shell. If your website runs on WordPress, it runs on PHP, so this affected you whether or not you had ever heard of it.

I protected the sites I look after before the fix existed, and updated them as soon as the fixed versions were published. This is what happened, what the flaws could do, and what to ask your own web host.

What happened

• Tuesday 20 October, evening. PHP published an advance warning that a critical security release was coming. It said nothing about what was wrong or which versions were affected, only that everyone should be ready to update.
• Wednesday 21 October, 14:00 UTC. The fixed releases arrived: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• The same day. Attack traffic was already being reported. Tenable’s summary of vendor reports says Amazon’s threat intelligence team had seen an exploitation attempt on 17 October, four days before the fix existed, and that Cloudflare and others saw attacks on the day of release.

Two sets of dates matter. One is when the fix was published. The other is when attackers started. For this flaw, the second came first.

What PHP2Shell is

PHP is the programming language that runs WordPress. WordPress itself, your theme and your plugins are all written in it, and they sit on top of a copy of PHP installed on your web server. The flaws are in PHP, underneath WordPress, not in WordPress.

There are two of them, tracked as CVE-2026-109618 and CVE-2026-109619. Both score 9.2 out of 10 on the CVSS v4.0 severity scale, which is the critical band. PHP’s own advisory says both can be exploited by an unauthenticated remote attacker. That means no login, no stolen password and no vulnerable plugin. A stranger sends the right requests to your website, and your server may run code of their choosing. How easy that is depends on how PHP is set up, which is why so much of the interim advice is about settings.

How they work, without the jargon

I’m deliberately not describing how to trigger either flaw. In plain terms:

• The first happens when PHP runs out of memory part-way through setting up a request. It leaves some of its working data half-built, and the clean-up code that runs afterwards trusts that data as though it were finished. An attacker who can make a request fail in just the right place can turn that confusion into running their own code.
• The second is a hand-me-down problem. PHP keeps a reference to a visitor’s request data after the memory behind it has been freed, and a later request handled by the same worker can end up using that stale reference. Think of a hotel keycard that still opens the room after the guest has checked out and a new one has moved in. The confirmed route in is PHP’s session upload-progress feature. PHP also lists leaking the contents of a worker’s memory as a confirmed impact, and that memory can hold passwords, tokens and API keys.

PHP rates the risk highest for servers running PHP as an Apache module (mod_php), where a demonstrated attack can fire before any application code has run. That includes WordPress and every security plugin installed in it. A firewall plugin inside WordPress can’t block a request that is dealt with before WordPress starts.

The vulnerable code reaches back to PHP 5.4, released in 2012. It has been there for a long time.

Why an up-to-date WordPress site wasn’t enough

This is the part that surprises people. You can do everything right inside WordPress: current core, current plugins, strong passwords, two-factor login. None of it fixes a flaw in PHP. The repair has to happen on the server, by whoever manages it, and until it does, the site sits in the gap.

What it could do to a WordPress site

Once an attacker can run code on your server, they act as your website. In practice that means they can:

• Read wp-config.php. It holds your database password and the secret keys that protect logins. With the database they have every page, every user, and for a shop, every order and customer record.
• Create a hidden administrator account, or plant backdoors in plugins, themes and the uploads folder. Tidying up the visible damage then doesn’t remove their way back in.
• Change what your visitors see. Typical results are spam pages added to your site to sell someone else’s products, redirects to scam sites, and card-skimming code added to a checkout.
• Delete or lock your files, including backups kept on the same server, and demand payment to give them back.
• Use your server to attack other people, sending spam or joining a network of hijacked machines. Hosts commonly suspend accounts that do this.

What that does to a business

A hacked website is rarely a one-day problem.

• Lost trade while it’s down, and again while search engines and browsers warn visitors away. Search rankings can take a while to recover even after the site itself is clean.
• A data breach. If customer details were reachable, UK GDPR expects a breach that puts people at risk to be reported to the Information Commissioner’s Office within 72 hours of you becoming aware of it, and the people affected may need to be told.
• Clean-up costs. Investigating, removing every backdoor, rebuilding from a known-good backup and changing every password and key costs far more than preventing it.
• Trust. Customers remember a card-skimmer on a checkout page longer than they remember the discount code.

For a small business with one website and no technical team, that’s a serious knock. This is why the hours between “a critical flaw has been announced” and “the fix is installed” matter.

What I did

When PHP’s advance notice appeared on the evening of 20 October, I treated it as an incident rather than a routine update. The notice gave no detail and no version numbers, so the safe assumption was that every PHP installation was in scope. I put interim mitigations in place on the sites I look after, so that nothing stayed fully exposed while the fix was being finished. When the fixed releases were published at 14:00 UTC on 21 October, I updated as soon as they were available.

What interim mitigations look like

PHP’s advisory lists stopgaps for anyone who can’t update immediately. In summary:

• Turn off PHP’s session upload-progress feature in the server’s own configuration, then restart PHP. Setting it from inside an application, or in a .user.ini file, is not enough.
• On PHP 8.5, turn off fatal error backtraces.
• Keep memory and request-size limits enforced at server level rather than leaving applications to override them.
• Restart all PHP workers after any change so it takes effect.
• Put a web application firewall in front of the site. Cloudflare published rules for the known attack patterns, including on its free plan, though they only cover traffic that passes through Cloudflare.

None of these make an unpatched server safe, and PHP says so. They narrow the gap. They don’t close it. The fix is the update.

What to do if you have a website

1. Find your PHP version. In WordPress, go to Tools, then Site Health, then Info, then Server. Your host’s control panel shows the same thing.
2. Compare it with the fixed versions: 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and later. Some hosts use packages from their Linux distribution, which can carry the fix without changing the version number, so ask them rather than guessing.
3. If you’re on PHP 8.1 or older, there is no official release for you. PHP published limited source backports for 7.4 to 8.1, and nothing for anything older. The real answer is to move to a supported version.
4. Ask your host in writing whether and when they patched. Managed and shared hosts usually apply PHP updates for you, but it’s reasonable to ask for confirmation. If you run your own server, the update is on you or whoever manages it.
5. Look for signs of trouble. Amazon’s advice is to start any investigation from 17 October. Check for administrator accounts you don’t recognise, recently changed files you can’t explain, PHP files in your uploads folder, unexpected outgoing email, and odd redirects or warnings from Google Search Console.
6. Keep backups away from the server they’re protecting, and check that one can actually be restored.

If something looks wrong, don’t start by deleting the strange file. That can destroy the evidence of how they got in and leave the backdoor behind. Stop, take a copy, and get someone to look at it properly.

Sources

• PHP security release announcement, 20 October 2026 (php.announce)
• PHP2Shell frequently asked questions (Tenable)
• PHP announces critical security release for two vulnerabilities (Qualys)
• A critical PHP security release is coming today, so get ready to update (Help Net Security)