PHP2Shell and PrestaShop: What Store Owners Need to Do

As of 23 October 2026, the PHP project has fixed both PHP2Shell flaws in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and PrestaShop has said there is no PrestaShop patch to install. Exploitation attempts are widely reported, but confirmed successful compromises are not publicly documented, and CISA has not added the flaws to its Known Exploited Vulnerabilities (KEV) catalog.

The short answer for merchants: your shop is exposed only if the PHP running it is unpatched. PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a pair of bugs in PHP itself, the language PrestaShop is built on. Updating PrestaShop or your modules will not fix it. The fix is a PHP update on the server, which in most cases your hosting provider handles.

PrestaShop shops have one extra problem. PrestaShop 1.7.8 and 8.x support only PHP 8.1 or older, and the PHP project ships no official PHP2Shell release for those branches. This guide covers what PrestaShop said, how to check your PHP, what to ask your host, and how to handle an older shop without rushing a risky upgrade.

What PrestaShop Said

PrestaShop's VP of Technology and Community, Krystian Podemski, published "Critical PHP security updates: what PrestaShop users need to know" on 21 October 2026. It is one of the clearest vendor statements on PHP2Shell. The key points:

• "These vulnerabilities are not in PrestaShop, nor in any PrestaShop module."
• "Updating PrestaShop or your modules will not fix this. There is no PrestaShop patch to install. The only complete fix is updating PHP on the server."
• "Security measures implemented at the application level, in PrestaShop or in modules, cannot block it."

PrestaShop says it will update the post if merchants need to take specific action, so check it again later.

One correction: the post names Quarkslab among the researchers who reported PHP2Shell. PHP's advisories credit researchers from Calif, Wiz and OpenAI, plus one other named researcher. Quarkslab did an earlier 2024 audit of PHP, which the PHP Foundation thanks separately.

Was PrestaShop Tested by the Researchers?

No. Calif confirmed unauthenticated remote code execution against 11 applications, including Magento and WordPress. Wiz demonstrated it against WordPress, Drupal and Joomla. PrestaShop is on neither list.

That is not a reason to relax. PrestaShop runs on PHP the same way the tested applications do. "Not named" means "not tested publicly," not "safe."

Check Your Shop's PHP Version

PrestaShop shows the PHP version in the Back Office:

1. Log in to your Back Office.
2. Go to Advanced Parameters > Information.
3. Read the PHP version in the server information section.

Then compare it with the fixed releases: 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Read the result the way PrestaShop advises. Linux distributions often backport fixes without changing the version number, so "If your version is lower than the one in the table, it does not automatically mean you are vulnerable, but it does mean you should check with whoever manages your server." Our guide on how to check your PHP version covers the hosting panel and command line as well.

Why PrestaShop 1.7 and 8.x Shops Are Most Exposed

PrestaShop's developer documentation lists the PHP versions each release supports:

Sources: PrestaShop's system requirements for version 9, version 8 and version 1.7.

PrestaShop says plainly that "PrestaShop 1.7 and 8.x shops typically run on PHP 7.x or 8.1." The PHP project says "PHP 8.1 and older no longer receive updates," but it did publish minimal source backports for 7.4, 8.0 and 8.1, and many distributions and long-term support vendors ship patched packages. So the question for an older shop is not "can I upgrade PHP?" (often you can't without upgrading PrestaShop), but "has my host installed a patched build of the PHP I run?" Our guide to PHP2Shell on PHP 8.1 covers where those builds come from. Several of the same vendors also ship patched 7.x builds, so ask your host which one it uses.

Don't Rush a PrestaShop Upgrade

PrestaShop advises against jumping to PrestaShop 9 under pressure: "Getting a patched PHP build for the version you run today is the immediate priority. Upgrading PrestaShop is a separate, longer-term topic: it is not an emergency fix for these vulnerabilities, and you should not rush a major upgrade to respond to them."

Do plan it, though. PrestaShop notes that running end-of-life PHP "leaves you dependent on others to backport critical fixes," that PrestaShop 9 "supports PHP 8.1 up to PHP 8.5," and that PHP 8.2 reaches end of life on 31 December 2026. A major upgrade means checking your theme and every module for compatibility, and taking a full, tested backup first (see our guide to backups and recovery). Our guide to upgrading old PHP safely covers testing on a staging copy first.

What to Ask Your Host (and What to Do If It's Your Server)

On shared, managed or PrestaShop-specialized hosting, your host manages PHP. PrestaShop suggests one direct question: "Has the fix for CVE-2026-109618 and CVE-2026-109619 been applied to the PHP version running my shop?" It adds: "Ask for a written confirmation." Our list of questions to ask your host has follow-ups if the answer is vague.

If you or your agency manage the server, PrestaShop's steps are:

1. Install the updated PHP packages from your Linux distribution, or the official PHP releases.
2. Restart every PHP process: PHP-FPM pools, Apache, LiteSpeed or FrankenPHP workers. As PrestaShop puts it, "An update that is installed but not loaded does not protect you."
3. If the shop runs in Docker, "rebuild your images on the updated base image and redeploy."

A generic example for Debian or Ubuntu with PHP-FPM (replace 8.1 with your version):

sudo apt update
sudo apt upgrade
sudo systemctl restart php8.1-fpm

On an old branch, confirm the fix through the package changelog, since the version number may not change.

Why Modules Can't Protect Your Shop

PrestaShop's statement is direct: "The attack can happen before PrestaShop code runs." Security modules, firewall modules and hardening modules are all PrestaShop code, so they load too late. You inherit the security of every layer you run on. Our guide to plugin, app and package security covers the layers you do control.

A WAF outside the server is different, and PrestaShop calls it "a very welcome extra layer during the patching window." It adds two warnings. First, "If your server can also be reached directly (by its IP address or another hostname), an attacker can bypass the WAF entirely," so make sure the origin only accepts traffic from your WAF provider. Second, a WAF "does not replace the PHP update."

Temporary Mitigations: What to Test

If PHP can't be updated right away, PHP's advisory lists settings that reduce exposure to specific paths. PrestaShop says these are for "technical teams, hosting providers and PrestaShop Experts" and "should be tested on a staging environment first." The full list, with what each one breaks, is in our guide to PHP2Shell interim mitigations. For a shop, watch for these:

• Lower upload limits. PHP suggests post_max_size of 8M without uploads or 32M with them. PrestaShop warns that shops need uploads for "product images, catalog imports, module and theme installation, and any third-party module that accepts uploads. Limits set too low can break these features."
• Session upload progress off. Set session.upload_progress.enabled=0 in php.ini, the PHP-FPM pool or server configuration, then restart all workers. Not in .user.ini or ini_set().
• memory_limit=-1. PrestaShop calls this "Advanced, for experienced server administrators only" and says it "must never be applied without a properly configured and enforced external memory limit (container or cgroup)."

Hiding errors with display_errors or error_reporting does not help, according to both PHP and PrestaShop.

Payment Modules, Customer Data and Taking the Shop Offline

Wiz warns that memory leaked through PHP2Shell "may contain passwords, authentication tokens, API keys and certificates." For a shop, that includes payment module credentials. After you patch, check for signs of compromise from 17 October 2026 onward. If anything looks wrong, or you can't rule it out, rotate payment API keys and admin passwords. Our guide on whether your site was hacked lists what to look for.

If your shop runs on PHP 8.1 or older and your host can't confirm a patched build, CISA says organizations that cannot update, or that use PHP 8.1 or earlier, "should take PHP-based systems offline until they can be patched or updated." Use a maintenance page or network restriction. Don't disable the PHP handler, which Beazley warns "can expose application source code and credentials."

Conclusion

As of 23 October 2026, PHP2Shell affects PrestaShop shops only through the PHP they run on, and PrestaShop has confirmed there is no PrestaShop or module patch. Check your PHP version in the Back Office, get written confirmation from your host that it is patched, restart PHP if you run the server, and plan your move off PHP 8.1 or older at a sensible pace. If you need help getting a patched PHP build onto your own server quickly, see our emergency PHP patching service. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions