PHP vulnerability: how serious is PHP2Shell and what to do

Since 20 October 2026, the PHP2Shell alert requires immediate checks on PrestaShop, WordPress and WooCommerce sites. This is not about a specific module or theme: it affects PHP core, the layer that executes your shop every day.

The key point that raises the priority is simple: both vulnerabilities are rated critical, with the possibility of unauthenticated remote code execution and memory leaks that can expose application secrets. If your site runs on an affected PHP branch, waiting for the next maintenance window leaves you unnecessarily at risk.

This article explains who is affected, how to verify the actual PHP version used by your site, what to do depending on your hosting, and how to plan if your shop is still stuck on an old branch.

PHP2Shell: what was published and why the alert is immediate

As of 23 October 2026, there is enough public information to act. fixes have been released and, by 22 October 2026, CERT-FR was already reporting known proofs of concept. For an e‑commerce manager the right reflex is therefore simple: check exposure, patch, then verify the shop’s state.

Timeline to remember since 20 October 2026

On 20 October 2026, PHP announced an imminent security release for two critical vulnerabilities. Details leaked before the embargo. Official fixes were published on 21 October 2026 at 16:00 Paris time, in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12.

The practical point for you: if your site does not run at least one of these patched versions, or a vendor package that explicitly backports the fix, consider it exposed. PHP also reminds that updating remains the only safe option: PHP security notice and patched versions.

The two flaws in one clear sentence

Here, PHP2Shell refers to two PHP core flaws: CVE-2026-109618, a corruption triggered by an out‑of‑bounds memory condition at request end, and CVE-2026-109619, a stale global request state reused by the next request in the same process, leading to use‑after‑free and memory leaks.

Both are rated 9.2 on CVSS v4.0. In plain terms: this is not a theoretical alert. By 22 October 2026, CERT-FR already reported known proofs of concept.

The severity is truly critical for an online shop

For a shop, the question is not only whether the server can crash. The real question is what an attacker can reach before you notice. On that point, the risk level is high.

Unauthenticated remote code execution: what that changes

PHP says both vulnerabilities may allow unauthenticated remote code execution. This means an attacker does not need a customer account, back‑office access or a pre‑compromised module to try an exploit. If the PHP engine at the other end is vulnerable, the exposure exists at the HTTP request processing level.

Cloudflare reported attack traffic immediately after public disclosure, confirming that the issue moved rapidly from warning to real‑world attempts to monitor: Cloudflare analysis of protections deployed against PHP2Shell. This does not prove targeted campaigns specifically against PrestaShop, WordPress or WooCommerce, and that distinction should be kept precise.

Memory leak: why passwords, tokens and API keys are at risk

The GHSA-6wmf-4rv5-p3rp advisory describes a global request state that can persist in a worker and be reused by the next request in the same process. The possible result: use‑after‑free, memory leakage, and potentially RCE. The other advisory, GHSA-w8hw-w9fx-j79w, concerns corruption from an out‑of‑bounds condition at request end.

For a merchant, the concrete consequence is simple: application secrets residing in memory can be exposed. This may include passwords, tokens and API keys. A shop may appear operational while keeping a serious risk to payments, connectors, customer area or administration. The mechanism for CVE-2026-109619 is described in the official advisory: GitHub advisory on RCE via stale global state.

Who is affected depending on your PHP version and hosting

The correct approach is to locate yourself on two axes: your PHP branch, then your execution mode. That pair determines urgency and the type of action required.

PHP branches to consider exposed

The officially patched branches start at versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12 for 8.2, 8.3, 8.4 and 8.5 respectively. All earlier versions of those branches are affected.

Branches 5.x, 7.x, 8.0 and 8.1 should also be considered at risk. Upstream support has ended for 8.1 and earlier. Vendor backports may exist for 7.4, 8.0 and 8.1 depending on providers, but remain limited. Nothing has been announced for 7.4. A common mistake is assuming that a PHP version available in a hosting panel is automatically safe. That is not sufficient.

Why Apache mod_php and PHP-FPM should be prioritised

Qualys recommends treating Apache mod_php as the most urgent case. PHP-FPM is also affected, as are php-cgi, FrankenPHP and LiteSpeed. If you don’t know how your site executes PHP, assume you must check without delay and then confirm with your host or managed service.

Practical point: a responding shop is not necessarily a protected shop. The risk targets the PHP engine itself. Qualys explains this and also notes that a vendor or host package may include the patch without displaying the exact upstream version number: Qualys PHP2Shell risk assessment.

The special case of shared hosting

On shared hosting, your provider may have patched clusters quickly, but you still need to check the PHP branch selected in your control panel. You can therefore have a responsive host while keeping your site exposed if you remain on an old branch such as 8.1 or earlier.

How to verify the actual PHP version used by your site

This is the simplest step, yet many get it wrong. The classic trap is to look at a CLI version or a hosting contract and assume the website runs on the same version.

PrestaShop: where to check in the back office

In PrestaShop, first check Advanced Parameters > Information. That shows the PHP version reported by the shop. Do this check before changing anything, then repeat it after intervention.

If your site reports a version older than 8.2.35, 8.3.36, 8.4.27 or 8.5.12 on a still‑supported branch, the action is clear: update immediately. If you are on 8.1, 8.0 or 7.x, also confirm whether your provider documents a backport. Without that confirmation, treat the shop as at risk.

WordPress and WooCommerce: the safest route

On WordPress and WooCommerce, go to Tools > Site Health. It’s the easiest way to see the PHP version used by the website. Again, do not rely first on what the server should use: verify what WordPress actually sees.

On environments with multiple sites or multiple pools, two applications on the same server can use different PHP configurations. This is a frequent mistake on VPS and dedicated servers after partial changes.

Why the CLI version can mislead

The php -v command in SSH can differ from the version used by the web process. You may therefore see a reassuring CLI version while the front end still runs a different stack.

Another common case: an OS or host package includes the patch without showing the latest upstream version number. On VPS, dedicated or managed offers, good practice is to cross‑check three things: the version seen by the CMS, the installed package versions, and the provider’s statement.

What to do now, in the right order

The correct order avoids two mistakes: patching incompletely, or restarting too late. Here is the useful sequence for a production site.

Update PHP or select the correct branch in your hosting panel

First reflex: apply the patched version if available. On shared hosting, this may mean selecting the correct branch in your control panel. On VPS or dedicated servers, it means updating distribution or provider packages.

If you are a PrestaShop merchant and the shop is already fragile in terms of availability, plan in parallel for an emergency PrestaShop intervention in case the branch change breaks the front, back office or checkout. And if you want to reduce the risk of outages on future incidents, keep handy the checks that prevent a failure from taking your shop down.

Restart PHP-FPM or Apache after updating

On a VPS or dedicated server, updating is not enough if affected processes do not restart. You must restart PHP-FPM or Apache according to the actual execution mode used by the site. Restarting is also part of measures to apply after a temporary mitigation.

Common mistake: update a package, check the site quickly, then forget that workers in memory still use the old state. For a flaw that specifically involves processes and memory, that detail matters.

Why a WAF or temporary mitigation is not enough

PHP states there is no complete mitigation and that updating is the only safe option. Temporary workarounds have a use, but they do not fix PHP. Officially cited mitigations include session.upload_progress.enabled=0 to reduce CVE-2026-109619 exposure, blocking unnecessary multipart requests, fatal_error_backtraces=0 on 8.5, and then restarting PHP processes. The GHSA advisory also mentions pm.max_requests=1 can reduce risk if performance is not critical.

A WAF can buy time. Cloudflare has pushed default protections for its WAF customers. But filtering does not remove the engine vulnerability. If the branch remains exposed, a residual risk remains.

If your shop is stuck on PHP 7.x or 8.1, start a planned migration now

This is the most uncomfortable case. In an emergency you want to reduce risk. In practice, an old shop does not always upgrade PHP without breakage. Treat the issue as a proper project, not a single click in a hosting panel.

Why upgrades sometimes break an older shop

When a shop remains on 7.x or 8.1, the blockage often comes from a known set: incompatible modules, an old theme, fragile overrides, and unmaintained connectors. Until those are addressed, you remain dependent on a branch that no longer offers the same support guarantees.

On PrestaShop, this is often the moment to review the riskiest components and identify a badly coded PrestaShop module before keeping it in production. The benefit is not only compatibility: it also reduces risk for future updates.

What checks to run if you already suspect a compromise

After patching, the absence of visible errors does not prove there was no compromise. If your PHP branch was exposed, have HTTP and PHP logs checked, confirm the actual execution mode used, then assess possible exposure of passwords, tokens and API keys present on the server.

The decision rule is simple: if you cannot rule out exposure of application secrets, plan to rotate them in the affected scope. Waiting for an obvious symptom is not a good method with a memory‑leak issue.

When to move from an immediate fix to a managed compatibility project

If updating PHP breaks the site, checkout or admin, switch back to project mode once the emergency is contained. List incompatibilities, decide what can be fixed quickly and what must be replaced, then test the upgrade in a separate environment before returning to production.

If your PrestaShop shop is stuck on an old PHP branch, I can help with one-off or monthly PrestaShop support to scope the upgrade and then secure monthly maintenance for a PrestaShop shop. Free diagnosis, response within 24 hours and quote within one working day.

Frequently asked questions

Is my PrestaShop, WordPress or WooCommerce site affected if I never touch PHP code directly?

Yes, potentially. PHP2Shell affects PHP core, not just custom code. If your site runs an exposed PHP branch, the risk exists even without recent in‑house development. The correct reflex is to check the PHP version actually used by the site, then confirm whether it is patched or whether your provider has published a documented backport.

How do I verify the actual PHP version used by my site, not just the CLI version?

On PrestaShop, look at Advanced Parameters > Information. On WordPress and WooCommerce, use Tools > Site Health. These are more reliable for the web application than a simple php -v. On VPS or dedicated servers the CLI version can differ from the front‑end. Cross‑check the CMS‑reported version, installed packages and your provider’s statement.

Has my shared host already patched the vulnerability, or do I need to act in the hosting panel?

Both matter. A shared host may have applied cluster patches or protections, but the PHP branch selected for your site still needs verification. If your control panel still shows 8.1 or an older branch, do not assume everything is fixed. Check the version the site uses and the host’s official communication.

Is a WAF rule or disabling session.upload_progress enough, or should I still update PHP?

You must still update PHP. Official advisories indicate updating is the only safe option. A WAF can reduce risk quickly, and session.upload_progress.enabled=0 can limit part of CVE-2026-109619’s surface, but these measures are temporary and incomplete. They buy time, they do not fix the PHP engine.

I’m still on PHP 8.1, 8.0 or 7.x: am I still vulnerable and is a fix available?

Treat these branches as at risk until a fix or vendor backport is explicitly confirmed. Upstream no longer supports 8.1 and earlier. Backports may exist depending on providers for 7.4, 8.0 and 8.1, but are limited. Nothing has been announced for 7.4. On an older shop, the main difficulty is often compatibility with modules, theme and connectors.

What simple signs should make me suspect a compromise before or after the patch?

Any unusual behaviour on an exposed shop warrants investigation, but the absence of visible symptoms does not reassure. With PHP2Shell the sensitive point is memory leakage. If your site ran on a vulnerable branch, have HTTP and PHP logs checked, confirm the execution mode used, then assess possible exposure of passwords, tokens and API keys. If doubt remains, plan to rotate the affected secrets.