PHP2Shell: what online stores should log in their risk register

Two critical flaws in PHP itself put every self-hosted WooCommerce, Magento and PrestaShop store on alert in October 2026. Patching comes first. But the event also exposed risks that will outlast this patch — and those belong in your risk register.

By Alex Martyushin, founder & risk consultant · Updated 30 October 2026 · 12 min read

What PHP2Shell is — the facts that are consistent

Coverage of PHP2Shell has been fast and sometimes contradictory, with different severity scores and different accounts of how widely it is being exploited. These are the points the official sources agree on. For anything that drives a decision — affected versions, mitigations, follow-up fixes — read the official PHP announcements and the two GitHub security advisories linked from them, because details have been updated since release.

Is your store exposed?

The question is not “which ecommerce platform do we use?” but “where do we run PHP that answers requests from the internet?”. Many businesses run more PHP than they realise.

Two points catch people out. First, a Magento or WooCommerce update does not fix PHP2Shell; the store software and the PHP runtime are patched separately, and you need both up to date. Second, the version number you see may mislead you. Linux distributions often backport security fixes into packages that keep an older-looking version number, while a command-line check can report a different PHP version from the one your web server actually uses. Confirm with your host or from the package changelog that the runtime serving the store includes the fixes for both CVEs.

What to do first

This is the short incident checklist. The detailed process — triage, priorities, SLAs, verification — is covered in our guide to a risk-based vulnerability management process, which uses PHP2Shell as a worked example.

1. List every PHP site and server. Production store, staging, blogs, microsites, admin tools, hosting panels. Check DNS records for subdomains you have forgotten.
2. Ask your host or agency in writing whether each environment runs a fixed PHP version or a vendor backport, and when it was applied. Keep the reply; it is your evidence.
3. Patch internet-facing systems first. Update PHP, then restart PHP-FPM or the web server so no worker keeps running the old code.
4. If you cannot patch today, apply the interim settings from the official advisory, restrict access (for example, put staging behind a login or IP allow-list), or take non-essential sites offline. Treat this as a short exception with an end date, not a fix.
5. Look for signs of compromise on anything that was exposed while unpatched: new admin users, unexpected PHP files in upload or cache directories, changed checkout templates or payment scripts, new scheduled tasks, unusual outbound connections. If you find something, treat it as a security incident and get specialist help before cleaning up, so evidence is kept.
6. Verify. Re-check versions after the change, and confirm your next external scan is clean.
7. Close the loop in the register, as described below.

Why it belongs in the risk register at all

A single critical vulnerability is not, by itself, a register entry. It is a ticket: find it, fix it, verify it. Filling the risk register with CVE numbers is a common mistake — the register becomes a patch log that nobody at board level reads.

What earns a place in the register is the underlying exposure the event revealed: things that will make the next critical PHP, WordPress or Magento flaw just as dangerous. Ask four questions after the dust settles:

• Did we know where all our PHP was? If a forgotten site turned up, the risk is an incomplete asset inventory.
• How long did patching take, and who controlled that? If the answer was “we waited for the host”, the risk is third-party dependency.
• Could we patch everything? If a legacy site is stuck on PHP 7.4 or 8.0, the risk is unsupported software.
• Can we prove we were not compromised? If logs were missing or nobody looked, the risk is undetected intrusion — and with it card data and personal data.

Each “no” is a risk with a cause, a consequence and controls you can improve. That is what the register is for.

Six risks to record after PHP2Shell

Below is an example set for a self-hosted online store, scored on a 5×5 risk matrix (likelihood × impact). Scores are illustrative residual scores for a store that has patched but not yet fixed the underlying gaps. Use your own scales and evidence.

Notice that none of these says “PHP2Shell”. The CVE is the evidence that raised the likelihood, and it belongs in the risk’s history and in the notes for risk 1. That way the entries stay valid for the next WordPress plugin flaw or Magento advisory, and you are not adding a new line every month.

A worked entry

Here is risk 2 written out in full, the way it would look in a register with proper fields:

The evidence line is an example of what to write, not a claim about any real provider. The difference between the inherent and residual scores is explained in our guide to inherent vs residual risk.

If you find signs of compromise

A compromised store is no longer a vulnerability management problem; it is an incident with legal and contractual deadlines. Add a register entry for the incident’s consequences while it is investigated, and make sure the people below are involved early.

• Payment provider and acquirer. If card data may have been exposed, your merchant agreement will set out who you must tell and how fast. The PCI DSS checklist explains which parts of your checkout are in scope.
• Data protection regulator. In the UK, a personal data breach that is likely to put people’s rights at risk must be reported to the ICO within 72 hours of becoming aware of it. In Australia, organisations covered by the Notifiable Data Breaches scheme must notify the OAIC and affected individuals of an eligible breach as soon as practicable. In the US, notification rules are set by state law and differ between states, so take advice.
• Insurer. Cyber policies often require prompt notification and use of their approved incident responders.
• Customers. Expect a rise in phishing that mentions your brand, and a later rise in fraud and chargebacks — see our guide to ecommerce fraud and chargebacks.

KRIs to track from now on

The useful lesson from a fast-moving vulnerability is measured in hours and days, not in the number of CVEs. These key risk indicators tell you whether you would cope better next time:

Thresholds are illustrative. Align the first one with any external rule that applies to you: the vulnerability management guide summarises the patching timeframes in Cyber Essentials and the Essential Eight.

What PHP2Shell teaches beyond PHP

The specific flaw will be forgotten within months. The pattern will repeat: a critical bug in a component everyone depends on, a patch and an exploit within days of each other, and conflicting news in between. Three lessons apply to any store.

Your platform is more than your platform

Store owners think in terms of “WooCommerce” or “Magento”, and keep plugins and themes up to date. Underneath sit the language runtime, the web server, the operating system and the hosting control panel. Each has its own security fixes and often its own owner. Write down who patches each layer — in a simple table, agreed with your host or agency — before the next emergency, not during it.

Responsibility can be outsourced; risk cannot

If your host is slow, the breach is still yours: your customers, your acquirer, your regulator. This is why hosting and agency relationships deserve the same treatment as any important supplier — due diligence, contract terms and periodic review. Our guide to cybersecurity risk assessment shows how suppliers fit into the wider picture of cyber risk.

Speed needs to be rehearsed

A 48-hour patch target means nothing if nobody has done it outside a scheduled release. A staging copy that matches production, a known way to roll back and an agreed rule that security fixes can bypass a trading freeze turn a crisis into an afternoon’s work.

Common mistakes

• Updating the store, not the runtime. A new Magento or WooCommerce version does not change the PHP version running underneath it.
• Trusting a version string. Backported packages can look old but be fixed, and the command-line PHP can differ from the one serving pages. Confirm with the host or package changelog.
• Forgetting to restart. Updated files on disk do not help while old workers are still running.
• Treating mitigations as a fix. The PHP project says its interim settings do not make an installation safe. Record them as a time-limited exception.
• One register line per CVE. Log the underlying exposure; attach the CVE as evidence.
• Patching and moving on. If a site was exposed while unpatched, check it for compromise before declaring the matter closed.
• Relying on news coverage. Early reports disagreed on scores, versions and exploitation. Use the vendor advisory and your national cyber security agency.