PHP2Shell: What Happened, What to Do Now, and When to Leave PHP Behind

On October 21, the PHP project shipped an emergency security release for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Security researchers have taken to calling the pair PHP2Shell, and CISA published an alert the same day urging organizations to patch immediately.

If your website runs on WordPress, Drupal, Joomla or a custom PHP application, this one is about you. Here is what happened in plain terms, what to do today, and the bigger question it raises.

What PHP is, and why one bug reaches so many sites

PHP is the programming language that runs on the server behind most traditional websites. When someone visits a WordPress page, the server starts PHP, PHP runs WordPress, WordPress pulls content from a database, and the result is sent back as a web page. This happens on every request.

That makes PHP the floor that everything else stands on. A flaw in a WordPress plugin affects sites using that plugin. A flaw in PHP affects every site running on it, whatever sits on top.

What PHP2Shell actually is

Both vulnerabilities are rated 9.2 out of 10 for severity, and both allow unauthenticated remote code execution. In everyday terms: an attacker doesn't need a password or an account. They send specially crafted requests to your site and can end up running their own code on your server, with the same access your website has.

The two bugs work differently:

• One is memory corruption that happens when PHP runs out of memory partway through a request. Researchers showed that a request with hundreds of empty file-upload fields can exhaust PHP's default memory limit while staying under its default upload size limit.
• The other is a "use-after-free" bug tied to state PHP keeps between requests. PHP reuses its worker processes, so damage left behind by one request can be picked up by the next.

The conditions for the second bug are met by a default setting, session upload progress, which is switched on in most installations. Researchers demonstrated working attacks against the latest WordPress, Drupal and Joomla releases.

How serious is it right now?

Serious enough to act today. Several public proof-of-concept exploits were available within a day of disclosure, which means attackers no longer need to work out the details themselves.

Reports on active attacks differ. Some security firms say they have seen exploitation attempts, including one reported days before the public disclosure, while others have not seen any on the systems they monitor. That disagreement is normal in the first days of a major vulnerability. It is not a reason to wait.

What to do today

1. Find out which PHP version your site runs. Your host's control panel will show it, or in WordPress go to Tools, then Site Health, then Info, then Server.
2. Update PHP to a fixed release: 8.5.12, 8.4.27, 8.3.36 or 8.2.35. On managed hosting, ask your host whether they have already done this. Many moved quickly.
3. If you are on PHP 8.1 or older, you have a bigger problem. Those versions are past end of life and get no official fixed release. The PHP team published source patches for 7.4 through 8.1, but applying them means building PHP yourself, which most hosting setups can't do. Upgrading to a supported version is the realistic path.
4. If you can't update straight away, ask your host or developer to switch off session.upload_progress.enabled in the PHP configuration as a stopgap. It reduces the risk from one of the two bugs. It is not a fix.
5. Updating WordPress, your theme or your plugins does not help here. The flaw is in PHP, underneath all of them.

If you believe your site may have been compromised, treat it as an incident: take a backup for evidence, rotate passwords and keys, and get someone who does security response to look at it.

The bigger question: does your website need a PHP server?

PHP2Shell will be patched and most sites will be fine. But it is worth noticing the pattern. In July, a separate pair of flaws in WordPress core, known as wp2shell, also allowed unauthenticated code execution on default installs, and attackers used it to plant backdoors on unpatched servers. That makes two critical "anyone on the internet can run code on your server" events for WordPress sites in roughly three months.

None of this means WordPress or PHP is badly built. It is the cost of the architecture. A traditional WordPress site runs code on a server for every visitor, and that server, its PHP version, its plugins and its database all need watching, patching and upgrading for as long as the site exists.

For a marketing site that mostly publishes pages and articles, that is a lot of moving parts to keep safe.

What a modern setup looks like

The alternative isn't exotic. It's how a growing share of marketing sites are built today, including this one.

• Static sites built with Astro are generated ahead of time and served as plain files from a global network. Visitors never trigger code on a server you maintain, so a flaw like PHP2Shell has nothing to reach. Content lives in a visual CMS such as Sanity, so marketing still edits pages without a developer.
• Framer hosts the whole site for you. There is no server, PHP version or plugin stack on your side to patch. Marketing designs and publishes directly.
• A headless CMS such as Sanity or Contentful suits content that feeds the website, a product and other channels at once.

To be clear, no stack is immune to security issues. Build tools, CMS accounts and third-party scripts still need care. The difference is how much of your attack surface is a live server running code on every request, and who is responsible for patching it at 2am.

When to migrate, and when not to

Don't migrate in a panic. Patch PHP first. A migration is a planned project that takes weeks, and your current site needs to be safe in the meantime.

Then take an honest look. Leaving WordPress makes sense when:

• Security patches, plugin updates and PHP upgrades take real time every month
• You are on an old PHP version and upgrading means breaking plugins or your theme
• Marketing can't publish without a developer
• A redesign is coming anyway

Staying is a reasonable call when the site is stable, your team is fluent in it, and someone maintains it well. Migrate because the platform is holding you back, not because of one headline.

How we can help

We move teams off WordPress and other PHP platforms onto Framer, Astro and headless CMS setups. A typical migration looks like this:

• An audit of your current site: pages, content types, plugins, integrations and what each one is actually doing for you
• A recommendation on where to go, based on who edits the site and how much content it carries
• Content moved by script, including posts, pages, custom fields and media
• Every indexed URL mapped to a tested 301 redirect, with titles, descriptions and structured data carried across, so search rankings come with you
• Forms, CRM, analytics and consent tools reconnected
• A launch, then Search Console monitored afterwards

A typical marketing site takes five to eight weeks, including content. If you want help deciding whether to move, or need a hand getting patched first, book a call with us. You can also read more about leaving WordPress, or the specific paths to Framer and Astro.