PHP vulnerabilities: what to do after PHP2Shell

PHP vulnerabilities are no longer just a technical team issue. This week, the PHP project and the U.S. cybersecurity agency (CISA) urged users to immediately patch two critical flaws in the language itself. PHP powers 69.3% of websites with a known server-side language, according to W3Techs. If your store or site runs on WordPress, WooCommerce, Magento, or Adobe Commerce, this affects you directly.

This article explains, without unnecessary technical jargon or exaggeration, what happened, which versions are at risk, why PHP platforms with many plugins face greater exposure, and when it makes sense to consider an architecture without PHP, using Medusa (commerce) and Sanity (content).

In this article:

• What PHP2Shell is and why it matters to business owners
• Which PHP versions are affected and when support ends
• Why WordPress, WooCommerce, and Magento carry so much risk
• How a headless architecture with Medusa and Sanity reduces risk
• What risks remain without PHP
• What to do this week

# What is PHP2Shell, and why does it matter to your business?

PHP2Shell is the name given to two critical vulnerabilities in PHP (CVE-2026-109618 and CVE-2026-109619), fixed on 21 October 2026. They allow an attacker without a username or password to execute code on the server hosting your site. In business terms, this could mean stolen customer data, altered prices, installed malware, or a store taken offline.

The official PHP advisory rates both flaws CVSS 9.2 and says they affect all installations handling web requests: PHP-FPM, mod_php, php-cgi, FrankenPHP, and LiteSpeed, with greater risk in mod_php. The PHP Foundation confirmed that remote code execution was demonstrated with the default mod_php configuration.

What makes this urgent is the speed. According to Tenable’s analysis, Amazon Threat Intelligence detected an exploitation attempt on 17 October, four days before disclosure, and researchers confirmed pre-authentication remote code execution in specific versions of WordPress, Drupal, Joomla, and Magento. Cloudflare CTO Dane Knecht reported seeing “early attacks.”

CISA’s recommendation (21 October 2026): systems that can’t be updated, or that run PHP 8.1 or earlier, should be disconnected until they can be patched. See the original advisory.

An important caveat for accuracy: at the time of publication, CISA said it had not observed confirmed exploitation, and these CVEs were not listed in its Known Exploited Vulnerabilities (KEV) catalog as of 22 October. Even so, the recommendation is to patch without delay.

# Which PHP versions are affected, and when does support end?

All supported branches received a patch; branches that had already reached end of life did not. According to php.net, PHP 8.2 receives security fixes only until 31 December 2026, and PHP 8.1 stopped receiving them on 31 December 2025. If your platform depends on 8.1 or earlier, there is currently no official version that fixes PHP2Shell.

The PHP advisory notes that minimal source-code patches (backports) are available for 7.4, 8.0, and 8.1, but applying them requires compiling PHP manually; most shared hosting providers won’t do this for you. End-of-life dates are listed at php.net/eol.

How many sites are still running old branches? W3Techs estimates that, among sites running PHP, 26.9% use version 7 and 7.7% use version 5, both unsupported. These are the sites most exposed to risk.

# Why do WordPress, WooCommerce, and Magento carry so much risk?

The risk doesn’t come from the language alone; it comes from the combination of the core, plugins, themes, and third-party extensions running on the same PHP server. Each component is another entry point, and many stores take weeks to update. PHP2Shell adds to that history; it doesn’t start it.

# WordPress and WooCommerce: the problem is plugins

The report State of WordPress Security in 2026 by Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem during 2025, 42% more than in 2024. 91% were in plugins, 9% in themes, and only 6 in the core. 46% had no fix when publicly disclosed, and the median time to mass exploitation was 5 hours. WooCommerce is, in fact, a WordPress plugin.

# Magento and Adobe Commerce: CosmicSting and SessionReaper

In Magento and Adobe Commerce, two recent flaws illustrate the pattern. Sansec, a firm specializing in ecommerce security, called CosmicSting “the worst bug to hit Magento and Adobe Commerce stores in two years” and observed stores being hacked at a rate of 5 to 30 per hour. A little over a year later, SessionReaper arrived.

According to Sansec, automated SessionReaper attacks affected more than 50% of Magento and Adobe Commerce stores worldwide. Both CosmicSting and SessionReaper were added by CISA to its catalog of actively exploited vulnerabilities.

To be precise: these vulnerabilities are in the applications, not in the PHP language. Well-maintained PHP can be secure, and major websites prove it. For a business owner, though, the key point is different: in a PHP monolith, the core, extensions, and admin panel share a server, so a single vulnerability can compromise everything. If you're already concerned about fraud in your ecommerce store, platform security is the first line of defense.

# How does a headless architecture with Medusa and Sanity reduce risk?

A headless architecture separates the store into independent components that communicate via API. With Medusa as the commerce engine and Sanity as the content layer, there’s no PHP interpreter on the server, content lives on a managed platform, and a vulnerability in one component doesn’t automatically expose the others. That reduces the attack surface.

# Medusa: the commerce engine, built on Node.js

Medusa is an open-source commerce platform (MIT-licensed core) that runs on Node.js and PostgreSQL. It manages products, carts, orders, payments, and inventory via API. Because commerce logic is exposed through API, the storefront can run on a separate server, and many integrations are built as custom modules, reducing reliance on a plugin marketplace.

# Sanity: content, off your server

Sanity stores content as structured data in its Content Lake and delivers it via API through a CDN. In practice, your team edits in Sanity Studio, an application that works with the Sanity API, without a PHP admin panel like /wp-admin running on your own server. Plus, structured content makes it easier to mark it up with structured data such as JSON-LD for search engines and AI engines.

This separation also makes it easier to connect the store to AI agents and assistants in a controlled way, as we explain in Function Calling and MCP in Ecommerce.

# Does headless mean zero risk without PHP?

No. Removing PHP eliminates one category of vulnerabilities, but adds others. Medusa depends on the npm ecosystem, API configuration and credentials can fail, and custom code can contain bugs. What changes is where the risk lies and how contained it is—not whether it exists.

The clearest example: in September 2025, CISA warned about “Shai-Hulud,” a worm that compromised more than 500 packages in the npm registry, the same ecosystem Node.js depends on. A headless store needs to pin versions, audit dependencies, rotate API keys, limit token permissions, and monitor its services just like any other.

The honest recommendation: headless with Medusa and Sanity makes sense when your current platform forces you to keep patching plugins, runs on an unsupported PHP branch, or you need to separate commerce and content to grow. If your PHP site is up to date, has few plugins, and is maintained by a team, an update may be enough for now.

# What should your business do this week?

First contain PHP2Shell, then decide on a strategy. These steps apply whether you stay on PHP or consider migrating:

1. Ask your hosting provider or agency which exact version of PHP your site runs, and request written confirmation that it is already on 8.2.35, 8.3.36, 8.4.27, or 8.5.12 or later, or that its Linux distribution has already applied the patch (Debian, Ubuntu, or RHEL sometimes do this without changing the version number).
2. If you use PHP 8.1 or earlier, follow CISA’s recommendation: isolate or disconnect the site until you upgrade to a patched branch.
3. Enable web application firewall (WAF) rules, such as those published by Cloudflare, as a temporary measure—not as a substitute for the patch.
4. Check that the CosmicSting and SessionReaper patches have been applied to Magento or Adobe Commerce, and that WordPress and its plugins are up to date.
5. Inventory your plugins and extensions: remove the ones you don’t use and note which haven’t been updated in months.
6. If you’re on PHP 8.2, schedule the migration before 31 December 2026.
7. Assess whether it makes sense to keep patching or move commerce to Medusa and content to Sanity.

If you operate in the region, our overview of technical solutions for stores in Latin America.

# Frequently asked questions

# Is my WordPress site affected by PHP2Shell?

Yes, if it runs a PHP version without the patch from 21 October 2026. The flaw is in PHP, not WordPress, so the solution is to update PHP to 8.2.35, 8.3.36, 8.4.27, or 8.5.12 or later. Ask your hosting provider to confirm.

# Is a firewall or WAF enough?

No. WAF rules, such as those published by Cloudflare, help as a temporary measure while you update, but they don’t fix the vulnerability. The official PHP patch is still essential.

# When does support for PHP 8.2 end?

PHP 8.2 receives security fixes only until 31 December 2026, according to php.net. After that, it will no longer receive official patches, as has already been the case with PHP 8.1 since 31 December 2025.

# Are Medusa and Sanity immune to vulnerabilities?

No. They eliminate PHP-specific vulnerabilities and reduce the attack surface, but Medusa relies on npm packages, and API or credential configurations can still fail. They require maintenance and monitoring.

# Is migrating to headless expensive or slow?

It depends on the catalog, integrations, and content. That’s why it’s worth starting with an assessment: some businesses only need to update PHP, while for others, migrating commerce to Medusa and content to Sanity makes sense.

# Conclusion: patch today, decide on the architecture at your own pace

• PHP2Shell (CVSS 9.2) requires an immediate PHP update; branches 8.1 and earlier have no official patch.
• PHP 8.2 loses security support on 31 December 2026.
• In WordPress and Magento, plugins and extensions account for much of the risk, as Patchstack, CosmicSting, and SessionReaper show.
• Medusa + Sanity reduce the attack surface by removing PHP and separating commerce from content, without eliminating npm and configuration risks.

In upcoming installments of this series, we’ll look at how to have an online store without PHP by migrating from Magento or WooCommerce to Medusa and how to build secure websites without PHP using Sanity instead of WordPress. If you’d like to review your situation, learn about our Medusa stores or our WordPress-to-Sanity migration.

# About the author

Arturo Sánchez Gándara is CEO of ai¹, a Guadalajara-based consultancy that designs online stores with Medusa and websites with Sanity, and helps companies adopt artificial intelligence and gain visibility in AI search engines.

# Referenced sources

• PHP: security announcement of 21 October 2026 (PHP2Shell)
• PHP: supported versions
• PHP: unsupported branches (EOL)
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• The PHP Foundation: Today's PHP security release
• Tenable: PHP2Shell FAQ
• W3Techs: use of PHP on websites
• Patchstack: State of WordPress Security in 2026
• Sansec: CosmicSting attack and defense overview
• Sansec: SessionReaper
• NVD: CVE-2024-34102
• NVD: CVE-2025-54236
• CISA: npm supply chain compromise (Shai-Hulud)
• Medusa: official repository
• Sanity: Content Lake