PHP2Shell vulnerability: why websites on older PHP versions need to act now

On 21 October 2026, the PHP team released a fix for two critical vulnerabilities known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). They allow an attacker to take control of a server remotely, without any login, using a single web request. Their severity score is 9.2 out of 10.

For most websites, the answer fits in one line: update PHP. But a significant part of the web cannot simply apply this fix. If your site runs on a PHP version older than 8.2, there is no official fixed release. The real solution is a deeper migration.

What happened

• 20 October: information about the two flaws starts circulating online ahead of the planned disclosure. The PHP security team publishes an advance notice announcing a security release for the next day.
• 21 October, 14:00 UTC: fixed versions PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released.
• In the following hours: Cloudflare reports the first attacks and deploys temporary firewall rules. Security firm Sansec had predicted mass attacks within fifteen minutes of the release.

The flaws were discovered by Wiz. According to the PHP team, they affect all PHP installations serving web requests. Wiz also reports that versions going back to PHP 5.4 (2012) are vulnerable. Since PHP powers WordPress, WooCommerce, Magento, PrestaShop, Drupal and Sulu, the vast majority of corporate websites, online shops and customer portals are affected.

What these flaws allow

An attacker can run any code they choose on your server. In practice, that means stolen customer data, malware installed on your server, defaced pages or your server being used to attack other targets.

The PHP team is clear: there is no complete protection through configuration. Updating is the only safe option.

How to fix it

If your site runs on PHP 8.2 or later (8.3, 8.4 or 8.5), the solution already exists: the fix was released on 21 October. You just need to move to the latest version of your branch (8.2.35, 8.3.36, 8.4.27 or 8.5.12).

This update is not done from your website's admin panel: it happens on the server. Contact your hosting provider or your web agency now so they can apply it and check that everything works. On shared hosting, the hosting provider usually takes care of it. On a dedicated server or one managed by your agency, the agency handles it. The operation is quick and has no impact on your site's content.

The real issue: PHP versions without an official fix

PHP only maintains its four most recent branches: 8.2, 8.3, 8.4 and 8.5. Anything older is end of life and no longer receives official security releases.

Given how severe these flaws are, the PHP security team made an exception: it published minimal source patches for PHP 7.4, 8.0 and 8.1, and some Linux distributions and long-term support vendors provide backported fixes. These help in the short term, but they depend on your hosting provider and do not make an outdated version safe over time.

Important: "PHP 8" does not mean "up-to-date PHP". A site on PHP 8.0 or 8.1 without a backported patch is as exposed as a site on PHP 7.4.

Why migrating is harder than a simple update

Moving from 8.3.35 to 8.3.36 takes minutes and changes nothing in how the site works. Moving from PHP 7.x to PHP 8.3 is a different project:

• The code is no longer compatible. PHP 8 removed or changed many functions. A site built for PHP 7 often shows a 500 error as soon as the version changes.
• The CMS has to follow. An old version of WordPress, PrestaShop 1.6 or 1.7, Magento 1 or an old Drupal does not run on PHP 8.2 and later. The CMS must be updated first, sometimes to a new major version.
• So do extensions and themes. Modules, plugins and custom developments must be checked one by one. Some are no longer maintained and need to be replaced.
• Everything must be tested. Forms, payment, booking engine, customer login, emails: every critical journey must be checked before going live.

Depending on the age of the site, this means a few days to several weeks of work. And in the meantime, the site remains exposed.

PHP 8.2: fixed, but not for long

Sites on PHP 8.2 receive the fix, but this branch reaches end of life on 31 December 2026. The next vulnerability will not be fixed. If you need to plan an upgrade anyway, go straight to PHP 8.4 or 8.5.

What is at stake for your business

Your customers' data. A flaw like this gives access to everything stored on the server: customer databases, orders, bookings, contact forms.

Your legal obligations. In Switzerland, the revised Federal Act on Data Protection (nFADP) requires you to report to the FDPIC, as soon as possible, any data security breach likely to result in a high risk for the people concerned. In the European Union, the GDPR requires notification within 72 hours. Running a site on a version known to be vulnerable makes it hard to show that appropriate security measures were in place.

Your visibility. A compromised site can be flagged as dangerous by Google and browsers, injected with spam links or redirected to other sites. Traffic, search rankings and visitor trust suffer for a long time.

Business continuity. CERT-EU recommends isolating from the public internet any application that cannot be fixed. For a site on PHP 7, that can mean taking it offline during the migration.

How do I know if I am affected?

Two questions are enough: does your site use PHP? If so, which version?

Does your site use PHP? It does if it runs on WordPress, WooCommerce, PrestaShop, Magento, Drupal, Joomla, Sulu, Symfony or Laravel. If in doubt, ask your agency or hosting provider. A static site or a site hosted on a platform such as Shopify or Wix is not directly affected: the update is then the platform's responsibility.

Which PHP version? There are several ways to find out, from the simplest to the most technical:

• From your CMS: WordPress (Tools > Site Health > Info > Server), PrestaShop (Advanced Parameters > Information), Drupal (Reports > Status report), Magento 2 (the version is not shown in the admin panel, ask your hosting provider).
• From your hosting provider's control panel. The PHP version is usually shown in the site or hosting settings (under "PHP", "Configuration" or "PHP version"). If you have several sites, check them one by one: each can have its own version.
• By asking your provider. Your agency or hosting provider can give you the exact version within minutes, for all your environments.

Then read the full number. The last digit matters as much as the first two:

• 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later: you are protected against PHP2Shell.
• 8.2, 8.3, 8.4 or 8.5 with a lower number: you are vulnerable, but the fix exists. It needs to be applied.
• 8.1, 8.0 or 7.4: there is no official fixed release. Ask your hosting provider whether a backported patch has been applied, and plan a migration.
• 7.3 or older: you are vulnerable and no fix is coming. A migration is required.

Two pitfalls to avoid:

• The version shown on the command line (php -v) is not necessarily the one used by the site. A server can run several PHP versions side by side. Check the one used by the website itself.
• Do not forget secondary sites. Staging, subdomains, an old site still online, a campaign landing page: each one is a possible way in.

What to do now

1. Check your PHP version using the method above, for each of your sites.
2. If you are on PHP 8.2 or later: ask your hosting provider or agency to apply the fix without delay and restart the PHP services.
3. If you are below PHP 8.2: ask your hosting provider whether a backported patch is available, and make the migration a priority. In the meantime, ask your provider to put the available mitigations in place (web application firewall, blocking file uploads, disabling certain PHP options). They reduce the risk without removing it.
4. Make a full backup of your files and database. Keep a copy off the server.
5. Watch for warning signs: modified files, new admin accounts, unknown pages or redirects, a sudden rise in server load.
6. Check all your environments, not just the main site: staging, subdomains, old versions of the site still online, Docker containers (to be rebuilt from fixed images).

A wake-up call with a simple lesson

PHP2Shell will not be the last critical vulnerability. The difference between a site that is fixed in ten minutes and a site that has to be taken offline comes down to one thing: the PHP version it runs on. Keeping your site on a supported branch is not a technical luxury. It is what lets you react in time.

Is your site running on an old PHP version? Our team checks your setup, assesses the scope of the migration and supports you until the site is safely back online. Contact us.

Sources: php.net, Tenable, ma.ttias.be, Cyberial, Wikipedia.