Critical PHP security vulnerability (October 2026): what PrestaShop and OpenCart owners should do

Marius, PHP developer · Published 2026-10-21

On 21 October 2026 the PHP project published a security advisory: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that allow an attacker to execute code on the server remotely, without logging in to the website. The PHP project urges all PHP users to update immediately.

PrestaShop, OpenCart and many other websites and online shops run on PHP, so this advisory most likely concerns your website too. In this article I explain in plain terms what happened, how to check your PHP version, what to ask your hosting provider and what to do if your site still runs on an old PHP version.

What happened

The PHP project fixed two vulnerabilities. Both are rated 9.2 on CVSS v4.0 (out of 10), which is critical. In both cases the problem is in PHP itself, not in PrestaShop, OpenCart or another system, so updating the shop software or its modules does not fix it – PHP has to be updated.

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) – remote code execution via memory corruption when PHP runs out of memory. Out-of-memory handling can interrupt PHP while internal request data is only partially initialised, and the cleanup that follows may treat invalid data as valid.

• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) – remote code execution via stale global state. State that belongs to a request can survive after its memory has been freed, and a later request in the same PHP worker may use it.

According to php.net, an exploit has been demonstrated in which a single unauthenticated request triggers the attack before any application code runs.

Which websites are affected

According to php.net, all PHP installations that serve web requests are at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The highest risk is with Apache mod_php: this is where the attack that runs before any application code was demonstrated.

In other words, if your PrestaShop, OpenCart or other PHP website runs on a PHP version without these fixes, it is vulnerable. The fixed versions are:

• PHP 8.5 – 8.5.12 or newer;

• PHP 8.4 – 8.4.27 or newer;

• PHP 8.3 – 8.3.36 or newer;

• PHP 8.2 – 8.2.35 or newer.

The PHP project does not release updates for PHP 8.1 and older (more on that below). Linux distributions received the patches in advance, so on servers where PHP comes from distribution packages the fix may be installed without the main version number changing. The version number therefore does not always tell the whole story – in that case it is best to confirm with your hosting provider.

How to check your PHP version

1. In your hosting control panel. Most hosting control panels have a section where the PHP version is shown and selected (for example “PHP version” or “Select PHP Version”). Note that different domains or folders can be set to different versions.

2. In the PrestaShop back office. PrestaShop shows the server’s PHP version under Advanced Parameters → Information.

3. With a temporary phpinfo file. Upload a file with a hard-to-guess name containing the single line <?php phpinfo(); to your website folder, open it in the browser and check the version. Delete the file immediately afterwards – it shows a lot of server configuration details that should not be public. The “Server API” line in the same output shows how PHP runs (for example FPM or Apache 2.0 Handler, i.e. mod_php).

4. Ask your hosting provider. This is the most reliable way to find out not only the version but also whether the fix has been installed.

What to ask your hosting provider

If your website is on shared hosting, PHP is updated by the hosting provider. A short message with these questions will quickly clarify the situation:

• Has PHP on the server running my website been updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or have distribution packages with the fixes for CVE-2026-109618 and CVE-2026-109619 been installed?

• Are the fixes installed for every PHP version I can select in the control panel?

• How does PHP run for my website – PHP-FPM, Apache mod_php, LiteSpeed or something else?

• Were the PHP workers restarted after the update, so that the new version is actually running?

• If I use PHP 8.1 or older: do you provide security fixes for that version, or should I move to a newer PHP version?

If you run your own server and install PHP from the rpms.remirepo.net repository, note that php.net urges switching to distribution packages or building PHP from source, as no updates were available there on 21 October.

What to do if you are on PHP 8.1 or older

The PHP project does not release updates for PHP 8.1 and older. Some Linux distributions and long-term support (LTS) vendors backport fixes themselves, and for those who build PHP from source, php.net has provided minimal patches for 7.4, 8.0 and 8.1. For most website owners, however, the real solution is to move to a supported PHP version.

This is where the most common problem lies: older PrestaShop and OpenCart versions may not run on newer PHP. Even if the shop itself runs, modules or the theme may not be compatible – for example payment, shipping or product import modules. If you simply switch the PHP version in the control panel, the shop may stop working, or some features may break without anyone noticing.

That is why I recommend this order:

1. make a full backup of the website and the database;

2. find out which PrestaShop or OpenCart version you have and which modules and theme are installed;

3. check their compatibility with a newer PHP version – ideally on a copy of the website, not on the live shop;

4. fix or update incompatible modules, the theme or the shop software itself;

5. only then switch the PHP version and test the key processes: product search, cart, checkout, payment, emails and imports.

When choosing the new version, keep in mind that PHP 8.2 reaches end of life on 31 December 2026. If your shop is compatible, it makes sense to go straight to a newer version so you don’t have to repeat the same work in a few months.

This is where I can help: I check whether your PrestaShop, OpenCart or other PHP website, its modules and theme will work with a newer PHP version, fix incompatibilities and help you move to the new version safely.

Temporary measures if you cannot update right away

php.net lists several temporary measures that reduce exposure but do not make a website safe. The only full fix is updating PHP. These settings are meant for server administrators; on shared hosting you usually cannot change most of them yourself – that is the hosting provider’s job.

• memory_limit=-1 set via php_admin_value, so the application cannot override it;

• a low post_max_size (8M without file uploads, 32M with uploads), with upload_max_filesize below it;

• request size limits in the web server or reverse proxy;

• a memory limit for the container or cgroup (not RLIMIT_AS or RLIMIT_DATA);

• session.upload_progress.enabled=0 in php.ini or the FPM pool configuration (not via ini_set or .user.ini), followed by restarting the PHP workers;

• on PHP 8.5, fatal_error_backtraces=0;

• removing invalid or deprecated settings that are changed per request;

• fixing fatal errors and timeouts that an attacker can trigger.

Hiding errors with error_reporting, display_errors or the @ operator does not help.

Signs of compromise to look for

Updating PHP closes the vulnerability, but if someone used it earlier, malicious code that was already planted does not disappear on its own. So after updating it is worth checking for these signs:

• unknown PHP files in website folders, especially where they should not be – image, upload or cache folders;

• recently modified files nobody changed, such as index.php, .htaccess or core files;

• unknown administrator accounts in the PrestaShop or OpenCart back office;

• visitors redirected to spam or other unrelated websites, injected JavaScript in pages or in the database;

• unknown cron jobs on the server;

• unusual server load, spam sent from the server or warnings from your hosting provider;

• strange requests in the server logs, especially around the time other signs appeared.

If you notice any of these signs, don’t rush to delete anything: modified files and server logs help establish what happened and when. In that case a website security audit is worthwhile, along with changing the back office, FTP and database passwords.

In short: what to do now

1. Check which PHP version your website runs on.

2. If it is not a fixed version, ask your hosting provider to update PHP, or update it yourself if you run your own server.

3. If you are on PHP 8.1 or older, plan the move to a newer version and check the compatibility of your shop, modules and theme first.

4. After updating, check for signs of compromise.

Source: php.net security advisory “Security advisory: Critical remote code execution vulnerabilities, update now” (2026-10-21). This article reflects the information available on 2026-10-21; for the latest details see php.net.

Need help with a PHP update or website security?

If you are not sure which PHP version your shop runs on, whether it will work with a newer PHP version, or you suspect a compromise – get in touch. You can read more about what I do on the Website security: audit and hacked website cleanup page.

Write which system and version you use (PrestaShop, OpenCart or other), which PHP version you see and where the website is hosted. I reply within one business day.

Get in touch

← All articles

Do you have questions about PrestaShop or OpenCart modules, product import solutions, SilverStripe, or custom PHP development?

Write to me, and I will respond promptly to help you find the best solution for your business.