PrestaShop Store Owners: Fixing Your Shop After the PHP2Shell Disclosure

By Umair Ali Sadaqat · Updated · Editorial policy

PrestaShop shops on older 1.6 and 1.7 releases are often pinned to old PHP. Where to read your PHP version in the back office, how to patch with a host, and what to do when a module blocks the upgrade.

PrestaShop is popular with small European shops, and many of them run on budget shared hosting with an older PHP because a theme or paid module was never updated. That combination is exactly what makes the PHP2Shell flaws, fixed by the PHP project on 21 October 2026, a real concern for shop owners. Read the Black October overview for what the flaws are; here is what to do with a PrestaShop shop.

Step 1: read the PHP version from the back office

Open Advanced Parameters → Information. The server section lists the PHP version the shop runs on. Write down the full number.

You are fine on 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or newer in the same branch, or on a host build that includes the backported fix. If the panel shows 7.x, 8.0 or 8.1, keep reading.

Step 2: if you are on a supported PHP branch

Ask your host (or your server admin) to apply the patch release in your current branch and restart PHP. Staying inside the same branch avoids compatibility surprises. Afterwards, recheck the Information page and place a test order using your payment module's test mode or a low-value real item you then refund.

Step 3: if you are pinned to old PHP

This is the common case for shops on PrestaShop 1.6 or early 1.7. You have three choices, in order of how long they hold:

  • Get a host that backports. Some hosts run patched builds of older PHP through vendors like CloudLinux. Ask your host directly: "Is the PHP 7.4 (or 8.1) build my shop uses patched for CVE-2026-109618 and CVE-2026-109619?" A yes in writing is worth keeping.
  • Upgrade PrestaShop and PHP together. Plan the move to a current PrestaShop release on a supported PHP. Do it on a copy of the shop first, because themes and modules are where upgrades break.
  • Apply the stopgap while you plan. Turning off session.upload_progress at the server level and lowering request size limits reduces exposure to the confirmed attack paths. It does not make the shop safe. See the stopgap guide.

More on the options for old branches is in the PHP 7 and 8.1 guide.

When a module is the blocker

Find out which module actually fails on newer PHP before assuming the whole shop is stuck. On a staging copy, switch PHP to the new branch, turn on debug mode under Advanced Parameters → Performance, and browse the shop. Errors name the file and module. Often the module's developer has a newer release; sometimes a different module does the same job. A single abandoned module is rarely worth keeping a shop on unsupported PHP.

Shop-specific signs of compromise

Because attacks started before the fix, check after patching:

  • Team → Employees: any employee account you did not create.
  • The /img, /upload and /download folders for .php files.
  • Your payment module's files for recent changes you did not make.
  • Theme templates (.tpl files) for script tags that load from unfamiliar domains, a common way to skim card details on checkout pages.

The general steps are in was my site hacked.

Move your site to WeInc

If you are weighing an expensive PrestaShop upgrade against starting fresh, it is worth seeing what a hosted site would look like. Move your site to WeInc: first month free with code BLACKOCTOBER, until November 21, 2026. New customers only. Claim the offer

More in Blog

Alternatives mentioned in this article

Related guides and tools

Start building

How we research, test and update this page: our editorial policy. We.Inc is our own product.

Product

Who It's For

Features

Resources

Company

View Sitemap