PHP2Shell: is your WordPress or Magento store affected, and what do you do today?

Why is everyone saying patch today?

On Tuesday afternoon the PHP project posted a short notice: a security release was coming Wednesday at 14:00 UTC, 10 a.m. Eastern, for two critical flaws. Within the hour, BleepingComputer reported that details had leaked ahead of the planned disclosure. The fixes came out Wednesday morning, a little ahead of schedule.

PHP's own advisory doesn't soften it. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 "fix two critical vulnerabilities that can allow unauthenticated remote code execution." In plain words, someone who has never logged in to your site can send it a crafted request and run their own code on your server. PHP says every installation serving web requests is at risk, whether it runs as PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed. It rates mod_php highest, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." The release notes add: "There are no complete mitigations, updating is the only safe choice."

The researchers call it PHP2Shell. Wiz Research, which worked on it with researchers from Calif and OpenAI, says it showed remote code execution without a login against WordPress, Drupal and Joomla, and that an attacker can also read passwords, tokens and API keys out of the server's memory. Cloudflare says it saw attack traffic aimed at its customers after the leak. CERT-EU says initial proofs of concept have begun to circulate. The UK's National Cyber Security Centre is telling organisations to update, and, if they can't patch or apply the temporary fixes in time, to consider taking the system offline.

So this isn't a "sometime this month" update. If you run anything on PHP, today is the day to find out where you stand.

Is my WordPress, WooCommerce or Magento store affected?

If it runs on PHP and nobody has updated PHP since Wednesday morning, assume yes. Google Cloud's security team puts the vulnerable range at "All versions of PHP from 5.4 through 8.5.11". WordPress is written in PHP, and WooCommerce is a WordPress plugin, so every WooCommerce shop is in scope. Magento and Adobe Commerce are PHP too, and Cloudflare's write-up names WordPress and Magento as examples of what's exposed. The same goes for the quieter things: a PHP admin panel, a booking system, the wholesale ordering portal a developer built on Laravel a few years ago.

Here's where people trip. This is a flaw in PHP itself, the engine underneath your site, not in your theme or a plugin. Updating WordPress doesn't update the PHP underneath it. Your dashboard can show every plugin green while the server is still open. The researchers' own site says it plainly: "Updating an application does not update the PHP runtime beneath it."

Two things lower the risk without removing it. If your site sits behind Cloudflare's firewall, its protections have been on by default since late Tuesday Eastern time, on every plan with the WAF, including the free one. Cloudflare still tells customers to patch. And if your shop runs on a hosted platform where you never see a server or choose a PHP version, the question belongs to that platform. Read its status page rather than guessing.

How do I find out which PHP I'm on?

You don't need a developer for the first look.

• In WordPress: go to Tools > Site Health > Info and open the Server section. WordPress's docs describe it as the place that shows your server setup and PHP settings.
• In WooCommerce: go to WooCommerce > Status. The System Status report lists "PHP version" among the server details.
• In your host's control panel: many panels have a PHP settings page for each site that shows the version.
• On the server: php -v prints it. If your developer runs that, ask them to check the PHP that actually serves the website as well, because the command-line PHP and the web one aren't always the same install.

What you're looking for is 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or later in the same line. Anything below that is not fixed, with one big exception. Ubuntu and Red Hat often patch the old version number in place. Mattias Geniar, who is tracking the packages in a running patch guide, points out that Ubuntu 24.04 "still calls its PHP 8.3.6" after the fix, and his advice is to check the package version, not php -v. So on those systems a low number doesn't prove you're exposed; the package version is what counts. That check belongs to whoever runs the server, which is the next question.

Who actually installs the fix?

It depends on who runs the server, and plenty of owners aren't sure. Work out which of these you are.

A managed host. Managed WordPress and Magento hosts usually run PHP for you, so the patch is theirs to install. Your part is getting it confirmed in writing: which version or package each site is on now, and when it changed. Don't read silence as done.

Your own server, or a VPS your developer set up. Then it's you or your developer. Install the fixed PHP from the same place your PHP came from (your Linux distribution, a third-party repository, or Docker), then restart everything that runs PHP. A running process keeps the old PHP in memory until it restarts. Geniar's guide is specific about Apache with mod_php: "A reload or apachectl graceful is not enough." It needs a real restart. PHP-FPM needs a restart or reload, and queue workers need restarting too. One wrinkle on Red Hat-style servers: the popular volunteer-run Remi repository won't have fixed packages on release day, and PHP's advice, relayed by CERT-EU, is to switch to your distribution's packages or build from source.

Containers. If your app runs in Docker, Kubernetes or a service like Google Cloud Run, "redeploy" means something specific. PHP lives inside the image, so patching the machine underneath changes nothing. Someone has to rebuild the image on a fixed PHP base, push it, and replace every running container. Google's guidance for Cloud Run is to "rebuild with a patched version of PHP and redeploy" if you build your own image or automatic base image updates aren't switched on. On App Engine standard, supported runtimes (PHP 8.2 and newer) are patched automatically. When we looked at Geniar's package table at 11:37 a.m. Eastern, the official Docker php images were still marked "not yet", so a rebuild done too early can quietly pull the old PHP. Check the version inside the new container before you call it done.

A firewall rule buys time. It doesn't patch anything.

I'm on PHP 8.1 or older. Now what?

This is the hard spot. "PHP 8.1 and older no longer receive updates from the PHP project," the advisory says. Some Linux distributions and long-term-support vendors backport fixes, and PHP's security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves. Google is blunt about its own serverless platforms: unsupported runtimes "will not be patched."

Go in this order.

Ask whoever supplies your PHP whether a backported fix exists for your exact package. Sometimes it does. Ubuntu 22.04 ships PHP 8.1, and Geniar's table shows a fixed package for it.

If there's no fix, buy time and be honest about it. PHP lists temporary settings your developer can apply, including a memory limit change and turning off session upload progress, but says plainly that they "do not make an installation safe." NCSC's advice for systems that can't be updated or mitigated is to consider taking them offline. For a shop, that's a real business call. A maintenance page for a day is usually easier to recover from than a breach of your checkout.

Plan the upgrade now, not after the next one. Moving from 8.1 to a supported version can break old plugins, extensions or custom code, so test on a copy of the site first. And aim past 8.2: PHP's release note says 8.2 reaches end of life on 31 December 2026.

What do I send, and what do I check afterwards?

If someone else runs your server, send this today:

PHP released security fixes on October 21, 2026 for CVE-2026-109618 and CVE-2026-109619 (PHP2Shell). For each site and server you run for us, including staging and admin tools: which PHP version and package is it on now, is that a fixed build, and when was it installed? Have all PHP processes been restarted, and have container images been rebuilt and redeployed? If anything is on PHP 8.1 or older, what's the plan and the date? Please reply in writing today, even if the answer is "not yet."

Once they say it's done:

• Confirm it, don't assume it. Look at Site Health or the System Status report again, or ask for the package version on servers that backport.
• Check the side doors. Staging sites, an old microsite, the admin tool on a subdomain. NCSC tells organisations to find every system running PHP, "prioritising internet-facing systems".
• Look for signs of trouble. The PHP2Shell site lists warning signs such as unusually large or malformed session cookies, odd multipart (upload-style) requests followed by memory errors or repeated 500 errors, and PHP workers crashing or restarting for no clear reason. It also says none of these prove an attack on their own, and their absence doesn't prove you're fine.
• Treat keys on a server that sat unpatched as possibly exposed. Because the flaw can leak passwords and API keys from memory, ask whether payment, shipping and email keys stored there should be changed. We've written about rotating credentials without breaking things.
• Undo the stopgaps. Geniar's guide notes most early mitigations can be rolled back once the fixed PHP is running.
• Write down who owns PHP updates. If today was the first time anyone asked, fix that before the next one. A useful software handover names who keeps the platform patched.

If that message comes back with "we're not sure who handles that," it's worth sorting out properly. That's part of the work in our ecommerce practice for stores and checkouts, and in web applications for portals and admin tools. If you'd like a second pair of eyes on who owns what in your setup, tell us what you're running.

Related work: Paddle8.