PHP2Shell: the critical PHP vulnerabilities putting online stores at risk
🇬🇧 This article is also available in Romanian. / 🇷🇴 Vrei să citești articolul în română? [Click aici pentru versiunea în limba română].
Two critical PHP vulnerabilities, known as PHP2Shell, can affect online stores hosted on any server running PHP 5.4 or later. According to researchers at Sansec, they allow Remote Code Execution on the server. PHP will release the fix on Wednesday, October 21, 2026, at 14:00 UTC (17:00 Romania time).
Most vulnerabilities that researchers uncover affect a single platform. PHP2Shell, however, hits the very language that Magento, Shopware and WooCommerce run on. Sansec expects mass attacks to start within 15 minutes of the patch going public, so every hour of preparation counts.
What is PHP2Shell?
PHP2Shell is the name given to the two vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619. The PHP security team rated both 9.2 on the CVSS v4.0 scale, which puts them at critical severity.
Details about them were under embargo, but they leaked on October 20. Security firm watchTowr then confirmed that they are remote code execution vulnerabilities. At the same time, a screenshot of an exploit tool appeared, claiming it works against every PHP release from 5.4.0 onward.
Full technical details and the fixed versions will be published with the release. The PHP team reserves the right to ship the fix earlier if the details go public or attacks have already started.
Why you can’t fix it from your store’s code
The attack targets PHP itself and strikes before your store application even comes into play. A Magento update, a security module or an application-level firewall rule cannot fully protect you. The fix has to happen at infrastructure level, by updating PHP on your servers.
There is one more important detail: PHP only supports versions 8.2 and later. If your store runs on PHP 8.1 or older, you won’t get an official patch. You will need either a fix backported by your hosting provider, or a move to an officially supported PHP version.
Why does this matter for online store owners?
An attacker who can execute code remotely on your server can gain access to everything running on it. Depending on how far they get, the main risks include:
- Theft of credit card data and personal information: malicious scripts (skimmers) injected into the checkout page.
- Unauthorized database access: orders, customer data and account credentials can be compromised.
- Persistent backdoors: hidden admin accounts or access channels that stay active even after the patch and let attackers back in later.
- Loss of customer trust: on top of the high costs of investigation and cleanup.
What should you do now? (A short action plan)
- Check which PHP version you’re running: find out exactly which version runs on every server behind your store, not just production.
- Talk to your hosting provider today (October 21, 2026): if you don’t manage the server yourself, ask them to stand by and apply the update as soon as it’s released.
- Plan a move to a supported version if you’re on PHP 8.1 or older: unsupported versions won’t get an official patch.
- Apply the temporary mitigation recommended by Sansec: you’ll find the details in the FAQ at the end of this article.
- Update PHP as soon as the patch is out: then check that the new version is actually serving your store’s requests, not just the command line.
- Follow the official channels: keep an eye on php.net and the Sansec article, which will be updated as new information comes in.
Timeline (UTC)
- October 20, 2026, 15:20: a Hacker News post reports two upcoming PHP RCE disclosures.
- October 20, 2026: PHP announces a critical security release, and watchTowr confirms the leak.
- October 21, 2026, 14:00: scheduled PHP security release.
Protect your online store with CloudEBS
PHP2Shell shows that an online store’s security depends not only on the platform, but also on the server it runs on. At CloudEBS, we host online stores on our own hosting, optimized for e-commerce, including Magento, and we take care of PHP updates for our hosting clients.
How the CloudEBS team can help: we check your PHP version and server configuration, and we apply the temporary mitigations and the update as soon as it’s released. If you’re running an unsupported PHP version, we help you plan a safe migration.
Do you need a security audit for your store?
If you want to know how exposed your store is beyond PHP2Shell, we can run a security audit of your platform for you. We check both the application (version, patches, extensions) and the server it runs on, and at the end you get a report with the risks we found and the steps to fix them, in order of priority. The audit is non-intrusive, so your store keeps running normally throughout.
Drop us a line using the form below, and we’ll check together whether your store is ready.
Frequently Asked Questions (FAQ)
Sansec recommends two settings that may stop an attack before you get the chance to update PHP, though they are no guarantee. Add them to php.ini or to a separate .ini file under conf.d:
session.upload_progress.enabled = 0
session.use_strict_mode = 1PHP-FPM doesn’t read the command-line php.ini, so the settings have to be added to every pool that serves PHP, for example /etc/php/8.3/fpm/pool.d/www.conf:
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[session.use_strict_mode] = onAfter the change, reload the PHP-FPM workers (systemctl reload php8.3-fpm, with your version in place of 8.3), then confirm the values are active in a request handled by PHP-FPM, not on the command line. If you use mod_php, set the values in php.ini and restart Apache.
No. According to Sansec, both settings are safe on a typical store. Turning off upload progress only disables PHP’s native upload progress bars, which Magento doesn’t use, and strict session mode is what PHP recommends for every site.
No. If sessions are stored in Redis or in the database, as is the case for many Magento stores, session.use_strict_mode has no effect, neither protective nor disruptive. That’s why updating PHP remains the only safe route.