In short: If your online shop has been hacked or is running on an unpatched PHP version, three things are at stake at once: customer data, the checkout and your revenue. Put the shop into maintenance mode in a controlled way, preserve logs from 20 October 2026 onward, and clarify who updates and restarts PHP on your server.
What is at stake in an online shop
A shop is more than a website. It manages customer accounts with password hashes, delivery and billing addresses, order histories, vouchers and often interfaces to inventory management, shipping providers and marketplaces. Anyone who can execute code on the server can usually reach the database and the API keys stored there.
Card data is usually not stored with you but with the payment provider. That is only partly reassuring: an attacker can inject JavaScript into the order process that reads entries in the browser. Skimming scripts like this are hardly noticeable in day-to-day operations because orders go through as normal.
Then there are the interfaces. A shop that passes orders on to inventory management, shipping providers and marketplaces usually keeps the access keys for them in configuration files on the server. Anyone who copies them can create shipping labels in the merchant's name, change stock levels or misuse marketplace accounts.
Typical shop systems and why PHP2Shell affects them
The common shop systems among mid-sized businesses in Europe run on PHP: Shopware 6, WooCommerce, Magento, OXID, PrestaShop and many older Shopware 5 installations. PHP2Shell (CVE-2026-109618 and CVE-2026-109619, each CVSS 9.2) lies in PHP itself. Attackers need neither a customer account nor admin access.
For merchants this means: the latest shop update does not protect you. What matters is whether PHP on the server is at 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or whether the host has applied a backport, and whether all PHP processes were restarted afterwards. For old shops on PHP 8.1 or older, the PHP project no longer provides official updates. In that case, alongside the emergency there is a migration ahead of you, one you do not want to carry out under time pressure in the peak season.
Online shop hacked: what an incident actually means
A compromised shop causes damage on several levels that reinforce one another:
- Revenue: Every hour of maintenance mode costs orders. A shop that keeps running unnoticed, however, can become considerably more expensive.
- Customer data: Leaked addresses and orders are used for targeted phishing emails that look genuine because they mention real orders.
- Visibility: If Google detects malicious code, a warning appears in the search results. How to get rid of it again is explained in the guide Removing a Google warning.
- Partners: Payment providers and marketplaces have their own rules for security incidents. Anyone who reports too late risks trouble with settlement.
Who is responsible: agency, host or merchant?
In many shops, the question of PHP falls between all the chairs. The agency built the shop and maintains plugins, the host runs the server, and the merchant assumes that one of the two takes care of it. With managed hosting the host usually patches; with your own vServer, nobody does automatically.
| Task | Typically responsible | What to check |
|---|---|---|
| Update the PHP package | Host or server administrator | Written confirmation with package version |
| Restart PHP processes | Whoever manages the server | Time of the restart |
| Shop and plugins | Agency | Maintenance contract and access |
| Inform the payment provider | Merchant | Contractual reporting duties |
A PHP patch does not prove that nothing happened beforehand. If the shop was attacked between 17 October and the time of patching, planted code may keep running. Have this checked before you give the all-clear.
The first hours: a sequence for merchants
- Put the shop into maintenance mode or, if that is not possible, take it offline temporarily.
- Preserve web server, PHP and shop logs from 20 October 2026 onward before log rotation deletes them.
- Have the host confirm the PHP package version and the restart in writing.
- Renew admin passwords, API keys for payment, shipping and marketplaces, and database credentials, and do so only after the cleanup.
- Check the checkout, payment plugins and embedded scripts for changes.
If there are indications of a data leak, the 72-hour deadline under the GDPR is running. You make the legal assessment together with your data protection officer and, where applicable, your lawyer.
How does PHP SOS help?
- We remotely check the actual PHP package version, the operating mode (for example mod_php or PHP-FPM) and whether all workers were restarted.
- We examine shop files, database and checkout for webshells, skimming code and new admin accounts, and remove any malware found.
- We coordinate with your agency and your host so that shop maintenance and server operations do not run past each other.
- We document findings and measures in a form you can present to your payment provider, insurer and data protection officer.
- Afterwards we harden the server and, if you wish, take over ongoing monitoring.
Frequently asked questions
Do I have to take my shop offline because of PHP2Shell?
The BSI (German Federal Office for Information Security) recommends taking web servers offline temporarily if the PHP update cannot be applied immediately. For a shop, a maintenance mode with a notice page is often a better route than an error message. Once PHP is patched and all processes have been restarted, the shop can reopen.
Is the card data in my shop at risk?
In most shops, card data is not stored on your own server but with the payment provider. What is dangerous, however, is manipulated code in the checkout that captures entries before they reach the provider. That is why the checkout is part of every review after an attack.
Is it enough to update Shopware or WooCommerce?
No. PHP2Shell affects PHP itself, not the shop system. A shop update does not close the vulnerability, and a PHP patch does not remove malicious code that has already been planted.
Whom do I have to inform after a data leak?
Where personal data is involved, a notification to the data protection authority within 72 hours may come into play, and depending on the risk, informing the people affected as well. Contractual duties towards your payment provider and insurer come on top. You assess the individual case together with your data protection officer and a lawyer.