Critical PHP vulnerabilities: check your WordPress or PrestaShop site

Updated 22 October 2026. On 21 October, the PHP project released urgent fixes for two critical vulnerabilities, known as php2shell. If your business website uses WordPress, PrestaShop or another PHP application, ask whoever manages your hosting to confirm that both fixes are installed. A working homepage does not answer that question.

What happened, and why does it matter?

The official advisories identify CVE-2026-109618 and CVE-2026-109619, each rated critical at 9.2 out of 10 under CVSS v4. They concern memory handling inside PHP and can allow remote code execution without an attacker logging in. This describes a serious vulnerability, not proof that your particular website has been compromised.

ENISA and other European bodies recommend immediate action: identify PHP applications, coordinate with providers and prioritise systems exposed to the internet.

Which websites need an urgent PHP security check?

The PHP announcement covers all installations serving web requests, including PHP-FPM, Apache mod_php, CGI, FrankenPHP and LiteSpeed. The PHP team considers mod_php the highest risk. Different configurations have different attack conditions; using PHP-FPM does not justify skipping the update.

Check company websites, online shops, subdomains, older campaigns and test sites that remain publicly accessible. A custom-built website can also use PHP. Make a list of domains and identify who controls the runtime for each: the hosting company, your server administrator or a maintenance supplier.

What about Shopify and Shoptet?

Shopify: its engineering blog describes Shopify Core as a Ruby on Rails application. Shopify manages hosting and platform updates. A standard Shopify store should therefore not automatically be classified as a PHP website whose owner must update server PHP because of these flaws.

Shoptet: an official June 2026 article confirms that part of its codebase uses PHP. However, Shoptet manages hosting, updates and technical operations. Shop owners do not update its PHP themselves; ask Shoptet support to confirm remediation of CVE-2026-109618 and CVE-2026-109619. Using PHP alone does not establish that an unpatched installation is currently running.

Check external apps and integrations separately. Shopify supports PHP app development, while Shoptet's API documentation says addons run on their developers' infrastructure. If a connector, custom application or related website uses PHP, ask its administrator for the same patch confirmation. Confirmation from the main platform does not by itself establish the status of these separate systems.

Which PHP versions contain the fixes?

The PHP project published these corrected releases on 21 October 2026:

These are the upstream fixed versions for this announcement. Hosting and operating-system vendors may backport security patches while retaining an older-looking version number. Ask for confirmation covering both CVE identifiers and the installed package revision; do not judge a vendor package by its short version alone.

PHP versions before 8.2 no longer receive security fixes from the PHP project. If you use one, arrange a supported upgrade or obtain specific evidence of vendor security support.

WordPress and PrestaShop: where to check PHP

In WordPress, open Tools → Site Health → Info → Server. Record the PHP version and compare it with your host's confirmation. The hosting panel may also show the version selected for that domain.

WordPress explicitly states that these flaws are in PHP and require no WordPress release to resolve them. Updating WordPress, a theme or a security plugin does not install the PHP fixes. Keep those components maintained, but ask separately about the server runtime.

PrestaShop:

Open your shop's server or configuration information in the back office; the menu label depends on your PrestaShop version. If you cannot find it, request the effective PHP version from the host. Specify the shop's actual domain, because another domain on the same account may use different settings.

PrestaShop's official guidance advises contacting the provider to confirm the patch. Before changing PHP branches, have the maintainer check compatibility with your shop version, theme, payment modules and other integrations.

How to fix the PHP vulnerabilities safely

1. Assign responsibility. Agree who updates PHP, checks application compatibility and verifies the live result.

2. Prepare recovery. Take backups of files, databases and necessary configuration. Confirm how they can be restored and arrange a rollback plan.

3. Check compatibility. Where available, test the proposed patched runtime on a staging copy. A move to another PHP branch needs particular care.

4. Apply and activate the fixes. The administrator should update the PHP runtime actually serving the website and restart or replace every affected PHP worker. An updated command-line PHP binary alone does not establish that web requests use it.

5. Verify the business journey. Recheck the effective web runtime and test login, forms, uploads and integrations. For shops, include cart, checkout, payment and order confirmation using an agreed test procedure.

Record the package or runtime evidence, completion time and test results. “The update was installed” and “the website works correctly afterwards” are separate checks.

What should you ask your hosting provider?

You can adapt this message:

Please confirm whether the PHP runtime serving [domain] includes fixes for CVE-2026-109618 and CVE-2026-109619. Which runtime and package revision are active? If patches were backported, please identify the relevant vendor advisory. Have all affected PHP workers been restarted or replaced? If work is pending, when is it scheduled and what temporary protection is in place?

Who can help with a website security assessment?

If you need a PHP vulnerability fix, a WordPress security check or help coordinating a PrestaShop PHP update, send NezHost your domain, CMS, hosting provider and known PHP version. Do not send passwords through the contact form.

We can start by assessing the information available and clarifying who manages each part. We will then agree the scope and a proposal for any further checks or changes. A broader website security audit should have defined coverage and deliverables; one PHP update cannot certify the whole website.

Does a firewall replace the PHP update?

No. A web application firewall can reduce exposure during patching, but it is temporary protection rather than a complete fix. If patching cannot happen promptly, discuss restricting public access with the provider.

Can a website that looks normal still be affected?

Yes. Appearance and normal page loading do not establish patch status. Request runtime evidence. If you notice unexpected accounts, files, redirects or other suspicious changes, arrange investigation rather than relying on an update alone.

Does patching remove an earlier compromise?

No. Closing a vulnerability does not remove malicious files or restore trust in an already compromised installation. Suspected compromise needs a separate investigation and recovery plan.