Critical PHP Vulnerability Hits Magento, WooCommerce and Other Ecommerce Platforms: What We Know So Far

If your online store runs on Magento, WooCommerce, PrestaShop or Shopware, the critical PHP vulnerability disclosed on 21 October 2026 most likely affects you. The holes sit in PHP itself, so the update has to happen on the server that runs your store, not inside your store software.

You do not need to make that change yourself. This guide explains what happened in plain terms, what to ask your tech team, agency or host today, and gives them a cheatsheet to work from.

What we know so far

Updated 21 October 2026

• What: two critical security holes in PHP, the software that runs underneath most online stores.
• Who is affected: stores on Magento, WooCommerce, PrestaShop, Shopware and other PHP platforms, unless the host has already updated PHP.
• What has to happen: PHP on the server running your store has to be updated. Updates exist for PHP 8.2 to 8.5. Older versions need a bigger change.
• Attacks: Cloudflare saw the first attacks on the morning of 21 October, before the updates were out. The FBI and European agencies urge immediate action.
• What to do first: send this article to whoever runs your store (your developers, agency or host) and ask them to confirm the PHP update in writing.

What happened, in plain terms

On 21 October 2026, security researchers disclosed two serious holes in PHP, the programming language that runs underneath most online stores. PHP sits below your store software, much like an operating system sits below an app. The PHP project released updated versions the same day and asked every PHP user to update immediately.

The news travelled far beyond the tech world. Japan's prime minister asked the public to check whether their websites use PHP and to apply the update that night, in a post seen more than 33 million times.

Who found it, and what they found

The holes were found by researchers at Calif.io, Wiz, OpenAI and Quarkslab, working with the PHP project, according to Cloudflare's write-up. Cloudflare took part in the coordinated response and has published the clearest plain-language explanation so far.

In simple terms, PHP sets aside memory for every visit to a website and cleans it up afterwards. When a visit fails in a particular way, that cleanup goes wrong. An attacker can use the broken memory to run their own code on the server, or to read data that belonged to another visitor.

The holes are in PHP, not in Magento, WooCommerce or any plugin, so updating your store software will not close them. Ecommerce security firm Sansec reports that researchers ran the attack without a login against Magento 2.4.9, the newest Magento release, as well as WordPress and Drupal.

Why it matters

PHP runs 69.3% of websites whose server language is known, including most store software. No login or stolen password is needed for the attack, and both flaws are rated 9.2 out of 10 on the standard severity scale.

Official bodies on both sides of the Atlantic, including the FBI's Cyber Division, CERT-EU, Germany's BSI and the Dutch NCSC, agree on one message: update PHP now, and if you cannot, take the system offline until it is updated.

What an attacker can do to a store

Running code on the server means the attacker can act as your store. In practice, that opens the door to:

• reading customer records and order history
• adding a card skimmer to the checkout page
• changing prices or creating their own admin account
• pulling passwords, session tokens, API credentials for payments, ERP or shipping, and even the site's encryption keys out of server memory

For the business, any of these can turn into a data breach you have to report under GDPR, trouble with your payment provider, downtime and lost customer trust.

Why every hour without an update counts

Details of the holes leaked before the planned release, and CERT-EU reports that proof-of-concept attack code is already circulating. Cloudflare saw the first attacks at 07:43 UTC on 21 October, more than six hours before the updates came out, according to Sansec. Germany's BSI expects large-scale attacks within hours of the updates appearing.

The updates exist, but they protect a store only once PHP on its server has been updated and restarted. Until then, the hole stays open.

Is your store affected?

Most store software on the web runs on PHP. If your store runs on any of the platforms below, assume it is affected until whoever runs your server confirms that PHP has been updated.

Store platforms that run on PHP

These are the most common PHP-based store platforms, with their share of all ecommerce sites according to W3Techs:

Drupal Commerce, Sylius, Spryker, OroCommerce, Zen Cart and osCommerce also run on PHP. Share of sites says little about size: one Magento store can process more orders than thousands of small WooCommerce shops.

Store platforms that are not affected

Stores built on JavaScript do not run PHP at all. Medusa, the open-source commerce platform we build on at Rigby, runs on Node.js, so these two holes do not reach it.

Fully hosted platforms such as Shopify and BigCommerce run the servers for you, so the provider applies the updates.

What to do right now

PHP runs on the server, so nobody can change it from the store's admin panel. Your job is to get the right people moving and to get a clear answer from them. It takes three steps.

1. Send this to whoever runs your store

That means your in-house developers, your agency or your hosting provider, often more than one of them. If you are not sure who updates PHP for your store, ask all of them today.

2. Ask three questions, and get the answers in writing

• Which PHP version does our store run, on every server, including staging and test?
• Has the 21 October 2026 PHP security update been installed, and has PHP been restarted?
• If not, when will it be, and what protects the store until then?

Written answers protect you later. If something goes wrong, they show what was done and when.

3. If the update cannot happen today, protect the store

Some platform versions cannot run an updated PHP, and some teams cannot update today. In both cases, ask for one of these until PHP is updated:

• A firewall rule in front of the store. Cloudflare has protected its free and paid plans automatically since 21 October.
• A read-only store. Customers can browse the catalog, but cannot log in or place orders.
• Taking the store offline, as the FBI and the Dutch NCSC recommend for systems that cannot be updated.

The built-in maintenance mode in Magento or WordPress is not enough. PHP processes every request before the store checks the maintenance setting, so the attack can still run, Sansec warns.

Cheatsheet for your tech team

This part is for the people who will make the change. If you forward the article, point them here.

Find the PHP version

• WooCommerce and WordPress: Tools > Site Health > Info > Server. Stores hosted on WordPress.com, WordPress VIP, Pressable or WP Cloud are already protected, according to WooCommerce.
• PrestaShop: Advanced Parameters > Information.
• Magento, Shopware and others: check on the server, using the PHP version that serves web traffic, which can differ from the command line. The table below shows the likely range for each platform version.

What each platform version needs

Every store below is affected. The difference is how much work the update takes.

Sources: Adobe Commerce system requirements, PrestaShop system requirements, Shopware. Magento shows its version at the bottom of every admin page.

Which PHP update to install

Restart every PHP process after the update, because a redeployed store does not change the PHP version. If your servers install PHP from the Remi repository, Sansec reports the update was not available there on 21 October, so use your distribution's packages.

If you cannot update today

Stop PHP and serve a static maintenance page from the web server, since the built-in maintenance modes do not help. For a read-only store, reject every request except GET and HEAD at the web server. Sansec's write-up includes ready-made rules for nginx and Apache.

Watch for signs of an attack

The FBI asks organisations to watch web servers for PHP processes that suddenly launch command shells or download files. If you find signs of a break-in, isolate the server, keep the web server and PHP logs, and report it (in the US at ic3.gov).

In the EU, a personal data breach generally has to be reported to the data protection authority within 72 hours of becoming aware of it. Bring in your legal team as soon as you suspect one.

Why this keeps coming back

What makes this alert hard for many stores is the link between the platform version and the PHP version. Adobe supports Magento 2.4.6 until August 2027, but PHP 8.2, which it runs on, stops receiving security updates on 31 December 2026. That is about ten weeks away, so a store that updates PHP 8.2 today faces the same question again before the year ends.

Magento stores have had a hard autumn on top of this. In September, attackers used StyleSmuggler, a Magento flaw rated 10.0 (CVE-2026-75650), before a fix existed, and CISA added it to its catalog of exploited vulnerabilities. In October, Adobe released a fix for BlockStrap (CVE-2026-103849), another 10.0, which makes the PHP alert the fourth serious security problem for Magento stores in under seven weeks.

Extensions, themes and custom code tie a store to its PHP version, so a PHP upgrade often turns into a platform project. Our Magento migration guide walks through the options.

Where to go next

Update first, then plan. Once the immediate risk is handled, many teams will ask whether they want to go through this again with the next PHP release.

Medusa stores were not affected

Medusa runs on Node.js, not PHP, so these two flaws did not touch Medusa stores. Node had its own security update the same day, rated High, because no stack is free of updates.

The difference is the path. Updating Node means changing a version number and redeploying, not upgrading the store platform. Medusa requires Node 22.22.0 or newer in its current release, so it keeps projects on supported versions instead of holding them on old ones.

Fewer things on one server

A classic PHP store such as Magento runs the storefront, checkout, admin panel and access to customer data inside one application, usually on the same servers. When that server is breached, everything behind it is exposed at once, and taking it offline stops every sale.

A headless store on Medusa splits these into separate parts. The storefront runs on its own hosting and talks to the commerce backend through an API, without holding the database credentials. Separation does not remove the need to update, but it limits what one compromised server can reach.

What a move looks like

Medusa keeps store logic in modules that can be changed or replaced one at a time, so a store can move piece by piece. Our posts on phased replatforming with Medusa modules and the Medusa vs Magento total cost of ownership cover the details.

At Rigby, we run every migration through Canso, our AI-native delivery framework, starting with a 30-day discovery. We map the store's dependencies, score the risks and agree on the plan before any code moves. Our migration to Medusa page explains the process.

The short version

If your store runs on PHP, it is most likely affected, and the update happens on the server, not in your store software. Send this article to whoever runs your store today and ask them to confirm the PHP update in writing.

If your platform version cannot run an updated PHP, protect the store now and plan the platform upgrade. That is also the moment to ask whether you want to face this again with every PHP release.

FAQ on the PHP vulnerability

My host manages everything. Do I need to do anything?

Yes, one thing: confirm it. Ask your host which PHP version your store runs and whether the October 2026 security update is installed, and keep the answer in writing.

Does a firewall like Cloudflare protect me?

It reduces the risk while you update, but it does not replace the update. Cloudflare switched on protections for its free and paid plans on 21 October, but it still tells customers to update PHP.

I am on Magento 2.4.6. Am I safe?

Only once your store runs PHP 8.2.35 or newer. Magento 2.4.6 supports PHP 8.1 and 8.2, and PHP 8.1 gets no update, so a store on 8.1 has to move to 8.2 first. PHP 8.2 support ends on 31 December 2026, so plan the next upgrade now.

Is maintenance mode enough to protect my store?

No. The maintenance mode built into Magento or WordPress still lets PHP process every request. If you need to go offline, your team should stop PHP and show a static page from the web server.

If I move to a JavaScript platform, will I never need security updates again?

No, but the updates are smaller. Node released its own security updates on the same day. The difference is that updating Node is usually a version change and a redeploy, while updating PHP on an old store platform can mean upgrading the whole platform first.

Sources

• PHP, Security advisory: critical remote code execution vulnerabilities
• FBI Cyber Division, PHP vulnerabilities alert on X
• CERT-EU, Security Advisory 2026-018: Critical Vulnerabilities in PHP
• BSI, PHP: BSI warnt vor kritischen Schwachstellen
• NCSC-NL, Kwetsbaarheden PHP: patches beschikbaar, update nu
• Prime Minister of Japan Sanae Takaichi, post on X
• Cloudflare, Cloudflare deploys protections against php2shell vulnerability
• Sansec, PHP2Shell: Critical PHP RCE
• WordPress.org, Critical PHP Security Release
• WooCommerce Developer Blog, Critical Security Releases for PHP
• PrestaShop, Critical PHP security updates: what PrestaShop users need to know
• Adobe, Adobe Commerce system requirements
• W3Techs, Usage statistics of PHP for websites
• W3Techs, Usage statistics of ecommerce systems