eCommerce

PHP security flaws: what small online stores need to check

Arnaud Guedj·October 29, 2026·5 min

An orange robot in a blue cap uses a wrench to fix a crack in a small shop's wall with a golden padlock while little grey bugs scurry away.

If your online store runs on WordPress, WooCommerce, PrestaShop, or Magento, it runs on PHP, and since October 21, 2026, two critical flaws in that language have made it possible to take over a server remotely, with no password. The only real protection is updating PHP to version 8.5.12, 8.4.27, 8.3.36, or 8.2.35. A small business owner doesn't need to be a developer to make sure that's done: ask your hosting company or web agency three precise questions, and check the answer.

What happened with PHP in October 2026?

The PHP team rushed out fixes for two vulnerabilities rated 9.2 out of 10 that let an attacker run code on a server without logging in. They were announced on October 20 and patched on October 21, 2026.

According to PHP's official announcement of October 21, 2026, flaws CVE-2026-109618 and CVE-2026-109619 affect every installation that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. In plain English: pretty much every way of hosting a PHP website. The PHP team considers mod_php the riskiest setup, since a single anonymous request can trigger the attack before any of the site's own code runs.

CERT-EU, the incident response team for the EU institutions, warned on October 21, 2026 that proofs of concept were already circulating, meaning technical demos attackers can reuse. France's national CERT, CERT-FR, part of the ANSSI cybersecurity agency, reported exploitation attempts in its October 26, 2026 update. According to French tech outlet Blog du Modérateur on October 22, 2026, several French government services, including the Interior Ministry, went offline while they patched.

Why are online stores especially exposed?

Because PHP powers most of e-commerce, and a compromised server exposes your orders, your customer accounts, and your reputation. The flaw sits in the language itself, not in your own code.

According to W3Techs, as of October 29, 2026, PHP ran on 69.2% of websites whose server-side language is known. WordPress and WooCommerce, PrestaShop, Magento, and Drupal all depend on it. So even a perfectly maintained site stays vulnerable if the PHP version on its server hasn't been patched.

For a store, the diagnosis is quick. An attacker who can run code on your server can read your customer database, slip in a fake payment form, redirect your visitors, or use your site to send spam. The damage isn't just technical: a "dangerous site" browser warning in the middle of the holiday season, and November's revenue ends up in the recovery ward.

How do I check whether my site is up to date?

Ask for the exact PHP version running on each site and compare it with the patched versions. On WordPress, you'll find it under Site Health, in the Info tab, then Server.

Here's the minimum version for each branch, according to CERT-FR:

PHP branch	Minimum patched version
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1 and older	no official fix: upgrade

There's one trap worth knowing about. Hosting company GoDaddy explains in its October 22, 2026 note that on its shared hosting plans, the fix was applied without changing the version number, so a site can show 8.5.11 and still be protected. The version number alone isn't enough: get written confirmation from your host, including the date the fix was applied.

What if my site runs on an old PHP version?

That's the riskiest case: branches 8.1 and older no longer get updates from the PHP project. Plan an upgrade to a supported version, or at least get a fix from a specialized long-term support vendor.

This isn't a fringe issue. Again according to W3Techs, as of October 29, 2026, 26.5% of PHP sites were still on version 7 and 7.7% on version 5. As an exception, the PHP project released minimal fixes for branches 7.4, 8.0, and 8.1, but only for people who build PHP themselves, and it still recommends moving to a supported version.

An old PHP version is rarely an isolated oversight. It often points to a theme, plugins, or a payment module nobody has updated in years because nobody dares touch them. Use the moment for a full checkup rather than one more bandage.

Who has to install the update: me, my host, or my agency?

It depends on your hosting. On shared or managed hosting, it's your host's job; on a dedicated server or a VPS (virtual private server), it's yours or your technical partner's.

Shared hosting or managed WordPress: your host should apply the fix. Your job is to get it confirmed in writing.
VPS or dedicated server: nobody will do it for you. Linux distributions received the patches in advance, according to PHP; install the updated packages, then restart PHP and the web server.
cPanel or Plesk control panel: switch the version from the panel, after a backup.
Hosted platform such as Shopify: you don't run a PHP server, the platform handles it.

Also watch for software that bundles PHP without saying so: an invoicing tool, an intranet, or an old test store that's still online. CERT-EU recommends taking stock of every installation, not just your main site.

What if the update can't happen right away?

Take the site off the public internet until it's patched, as CERT-FR and CERT-EU recommend, and apply PHP's published workarounds in the meantime. They reduce your exposure, but the PHP team itself calls them incomplete.

In practice, a few hours of maintenance page costs less than a stolen customer database. If your site sat unpatched for several days, CERT-FR points to its response checklist for a compromised network edge device, which lists the first steps to make sure no intruder has settled in. One last point: on October 23, 2026, PHP disclosed a third flaw, CVE-2026-115560, which only affects unusual configurations and will be fixed in the next regular release. The recommended setting until then is session.upload_progress.enabled = 0, which you can pass along to your developer as is.

My prescription

This week, send three questions to your host or agency: which PHP version runs on each of my sites? Is the October 21, 2026 fix applied, and since when? Is the recommended setting for the October 23 flaw in place?
List everything that runs on PHP, including forgotten sites, test subdomains, and internal tools.
Schedule the upgrade of any 8.1 or older branch, starting with a full backup and a test on a copy of the site.
Subscribe to CERT-FR alerts (or your own country's CERT) so you don't learn about flaws like these from the news.
Write PHP updates into your maintenance contract, with a written deadline for applying critical fixes.

What I take away from thirty years of building online stores: the most expensive outages are rarely the most spectacular ones. They're the small updates everyone assumed someone else had done. One question asked to your host in time beats ten prescriptions after the incident.

Frequently asked questions

Is my WordPress site affected by the October 2026 PHP flaws?

Most likely, since WordPress and WooCommerce run on PHP. The flaws affect every installation that serves web requests, however the server is set up. Your site is protected only if your host has installed PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or confirms in writing that it applied the October 21, 2026 fix.

My site shows an older PHP version. Am I at risk?

Not necessarily. Some shared hosting companies, such as GoDaddy, applied the fix without changing the version number shown. The only way to be sure is to ask your host for written confirmation, including the date the fix was applied. If your site runs PHP 8.1 or older, though, plan an upgrade, because those versions are no longer maintained.

Is my Shopify store exposed to these PHP flaws?

Not directly. On a hosted platform like Shopify, you don't run a PHP server, and the platform takes care of its own infrastructure security. Still check your other tools: a WordPress blog next to the store, an old test site that's still online, or an internal tool may well run on PHP.

What if I can't update PHP right away?

CERT-FR and CERT-EU recommend taking affected servers off the internet until they're updated, for example behind a maintenance page. In the meantime, your developer can apply the workarounds published by the PHP team, which reduce the risk without removing it. If the site went several days unpatched, have someone check that no intruder has settled in.