Opens in a new tab

PHP2Shell, one week on: the risk to your business and three decisions to make now

Written by Trilogi – The Digital Agency
29/10/2026
Illustration: glowing security shield over a network with vulnerable points

In short

A week after the patches, millions of PHP servers remain exposed. What it means for an online store and which decisions leadership should make this week.

A week after the PHP2Shell patches, the question for a leadership team is no longer technical: it is how much business is exposed while the store’s server remains unpatched.

What happened

On 21 October, the PHP project released emergency patches for two critical vulnerabilities known as PHP2Shell. They affect the PHP engine itself and let an attacker run code on the server without a username or password. They carry a severity score of 9.2 out of 10 and affect almost every PHP version since 5.4. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Since then, attack attempts have been constant, and on 26 October the US cybersecurity agency added them to its list of flaws that are already being exploited. Even so, more than 32 million PHP services worldwide are still running a vulnerable version.

Why it matters to your business

PHP powers WooCommerce, PrestaShop and Magento, the platforms behind many online stores and B2B portals of mid-sized companies. A flaw like this does not affect one feature: it gives access to the whole server. And that server holds the orders, the customer data, the ERP integrations and, often, the credentials for payment gateways and marketplaces.

In our experience, the real cost of an incident like this is almost never the technical one. It is the hours or days without selling, the team stuck trying to understand what happened, having to notify customers whose data may have been compromised, and the trust you lose. For a store turning over €10,000 a day, three days of downtime mean €30,000 in sales that do not come back, before counting anything else.

One important nuance: keeping WordPress, WooCommerce or PrestaShop up to date is not enough. The patch lives in the server’s PHP version, which often depends on the hosting provider or on nobody in particular. And versions older than 8.2 no longer receive patches: if your store runs on one of them, the fix is not an update but a migration project.

The three decisions we would make this week

1. Know, don’t assume. Ask your technical lead or provider today for a written answer: which PHP version each environment runs (the store, staging, the back office and the integrations) and when the patch was applied.

2. Decide who owns the platform. If nobody can answer the first question within a day, the risk is not PHP2Shell: it is that the platform your online revenue depends on has no clear owner. It is a good moment to decide whether that maintenance should stay in-house or with a team offering 24×7 support.

3. Put a date on technical debt. If your store runs on an unsupported PHP version, plan the upgrade or migration now, with a budget and a timeline, instead of waiting for the next emergency alert.

What we would do at TRILOGI

On the platforms we manage, PHP updates are part of maintenance and are applied with prior testing so integrations do not break. When a company asks for help in a situation like this, we start with a quick review of versions, access and logs from the last few days, and then propose the plan: immediate patch, migration if needed, and a maintenance model that avoids depending on emergencies again. If you want to see how we work, here is our 24×7 managed eCommerce platform.

Every Tuesday, the 5 stories that matter: subscribe to the newsletter.