# PHP2Shell is why we'd avoid WordPress and build headless on Next.js

> PHP2Shell is a 9.2-rated PHP flaw, and WordPress runs on PHP. Why we'd pick a headless CMS on Next.js, and what to patch this week.

**TL;DR:** PHP2Shell (CVE-2026-109618 and CVE-2026-109619) lets an unauthenticated attacker run code on PHP servers that handle web requests, and WordPress runs on PHP. Patch today: update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. It is not a WordPress bug, but on a monolith like WordPress one hole in the runtime exposes the pages, the admin, the logins and every plugin at once. That is why we'd avoid it. Next.js has had critical CVEs too. The difference is that on Next.js with a hosted headless CMS, the vendor patches the backend and you bump a package and redeploy.

**Published:** 2026-10-23 | **Updated:** 2026-10-27 | **Categories:** CMS, Next.js
---

On October 21, 2026, the PHP project shipped fixes for two critical vulnerabilities now known as PHP2Shell. [CISA put out an alert the same day](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching) urging everyone to patch. WordPress runs on PHP, so a WordPress site on an unpatched PHP version is exposed. The bug is in PHP, though, not in WordPress. That doesn't make you any less screwed though.

We build sites on Next.js with a headless CMS, so we obviously *have a horse in this race*. This post covers what PHP2Shell is, what WordPress site owners should do this week, the critical bugs Next.js has had, and how WordPress compares to a headless CMS. If you only need the fix, [skip to what to do this week](#what-to-do-this-week-if-you-run-wordpress).

We also recorded our take on PHP2Shell as a video. The transcript is on [the video page](/videos/is-wordpress-safe-after-php2shell-our-take).

## PHP2Shell lets an attacker with no account run code on a PHP server

PHP2Shell covers two CVEs. According to [Tenable's PHP2Shell FAQ](https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote), the PHP security team rates both CVSS v4 9.2 and says both can allow unauthenticated remote code execution.

| CVE | What goes wrong | CVSS v4 |
| --- | --- | --- |
| CVE-2026-109618 | Memory corruption when PHP runs out of memory while request data is only partly set up | 9.2 |
| CVE-2026-109619 | Use-after-free, where state left over from one request points to freed memory that a later request on the same worker uses | 9.2 |

CISA says the flaws "affect all PHP installations serving web requests." PHP lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and rates mod_php as the highest risk. The attacker does not need an account on your site.

The bug is old. Tenable cites Calif's technical writeup, which traced the earliest affected code path to PHP 5.4.0. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP security team also published minimal source backports for PHP 7.4 through 8.1 for people who build PHP themselves. PHP 5.4 through 7.3 get no fix from the PHP project.

Tenable quotes W3Techs putting PHP on 69.3% of websites whose server-side language is known. [W3Techs also puts WordPress](https://w3techs.com/technologies/details/cm-wordpress) on 58.3% of websites whose content management system it can detect, which works out to 39.6% of all websites. So nearly 40% of all websites are in a pretty bad spot.

### Exploitation reports differ

The sources disagree on whether PHP2Shell is being exploited at scale. CISA said on October 21 that it "has not observed exploitation of these vulnerabilities as of the time of publication." Tenable reports that Amazon Threat Intelligence saw an exploitation attempt on October 17, four days before disclosure, and now says PHP2Shell is being broadly exploited. The fix is the same either way, so patch.

## It is a PHP flaw, so updating WordPress fixes nothing

The [WordPress.org security notice](https://wordpress.org/news/2026/10/critical-php-security-release/) says the vulnerabilities "are not specific to WordPress and affect any server that hosts a PHP application. No WordPress update is required or planned for these issues."

WordPress core did nothing wrong here, and updating WordPress will not fix it. A WordPress site on an unpatched PHP version is still exposed, because the bug sits underneath WordPress. Tenable reports that Calif confirmed pre-authentication remote code execution against specific versions of WordPress, Drupal, Joomla and Magento.

WordPress ships its own security fixes on a regular schedule. [WordPress 7.1.3](https://wordpress.org/news/2026/10/wordpress-7-1-3-maintenance-and-security-release/), released on October 6, 2026, carried seven security fixes, and sites that support automatic background updates install it on their own. None of that helps this time. The weak point is the PHP runtime, and a WordPress update does not touch it.

## What to do this week if you run WordPress

At our team meeting the day after disclosure, our advice for one of our own WordPress clients was the same: keep PHP up to date in the meantime.

1. Check your PHP version. In WordPress, go to Tools, then Site Health, then Info, then Server. Most hosting panels show it too.
2. Get onto a fixed version, meaning PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. On managed hosting, your host may already be rolling this out. Ask them to confirm it in writing. Don't assume.
3. Check distribution packages properly. Tenable notes that Linux distributions and LTS vendors received the patches in advance. If you install PHP from your distribution, check your vendor's advisory, because a backported fix may not change the version number you see.
4. Treat PHP 8.1 or older as an emergency. WordPress.org notes that versions before 8.2 no longer get security updates from the PHP project. CISA says organizations that cannot update immediately, or that still run PHP 8.1 or earlier, should take PHP-based systems offline until they can be patched or updated.
5. Use a firewall as a stopgap only. CISA says a web application firewall "may provide some protection until systems are updated or patched." Cloudflare has deployed WAF rules and calls them a stopgap. Tenable notes the PHP security team says updating is the only complete fix.

If you run headless WordPress with a Next.js front end, the same steps apply to the WordPress server. The front end does not run PHP, but the WordPress admin and API behind it do.

## Next.js has had critical CVEs too

Moving to Next.js does not make security bugs go away, and we're not going to pretend it does.

- In December 2025, [Next.js published an advisory](https://nextjs.org/blog/CVE-2025-66478) for CVE-2025-66478, a critical flaw in the React Server Components protocol rated CVSS 10.0, that "can allow remote code execution when processing attacker-controlled requests in unpatched environments." It affected App Router apps on Next.js 15.x, 16.x and 14.3 canary releases. The advisory said "There is no workaround" and told teams that were online and unpatched to rotate their secrets.
- In March 2025, CVE-2025-29927, a [middleware authorization bypass](https://github.com/vercel/next.js/security/advisories/GHSA-f82v-jwr5-mffw) rated CVSS 9.1, was fixed in 15.2.3, 14.2.25, 13.5.9 and 12.3.5. The advisory notes that deployments hosted on Vercel were automatically protected.
- In January 2026, CVE-2026-23864, a high-severity denial of service bug, hit React Server Components across Next.js 13 to 16. We wrote up [how to patch CVE-2026-23864](/blog/react-server-components-cve-2026-23864-what-you-need-to-know) at the time.

Choosing Next.js changes where your code runs and who patches it. It still gets critical bugs, and you still have to deploy the fixes.

## A monolith puts everything behind one runtime

**On a classic WordPress site,** one PHP application does everything. It renders public pages, runs the admin, stores content in a database and executes every plugin you install. A hole in the PHP runtime exposes all of it. Patching means updating PHP on the server, which your host does on managed hosting and you do on your own server.

**On a headless CMS with Next.js,** the pieces are split. A hosted CMS such as [Sanity](/services/sanity) or Contentful runs the content backend, so patching their servers is their problem, not yours. As we say in the video, a vendor like Sanity has lots of enterprise clients it can't afford to let down. Your Next.js front end is an npm dependency that you upgrade and redeploy. Pages built at build time are static files served from a CDN, so there is no PHP, and no request-time code of yours, behind those pages. Server-rendered routes and Server Functions still run code, and those are the parts the Next.js CVEs above affected.

That split has a cost. You now have two systems to understand, a build pipeline and a developer in the loop for template changes. For some teams, one WordPress install with a good host is simpler.

The split paid off for us this week. None of the Next.js sites we build run PHP, so PHP2Shell does not apply to them. When the Next.js and React CVEs landed, we had to patch those sites like everyone else.

## WordPress vs headless CMS: a side-by-side comparison

The table below compares classic WordPress with a hosted headless CMS and a Next.js front end. We left cost out on purpose, because it depends too much on hosting, plugins and team.

| | WordPress (classic) | Headless CMS with Next.js |
| --- | --- | --- |
| Runtime | PHP on a web server | Node.js for the front end, vendor-hosted CMS API |
| Who patches the runtime | Your host, or you if you self-host | Your hosting platform for Node.js, the CMS vendor for the backend |
| How you ship a fix | Update PHP, WordPress core and plugins on the server | Bump the package version and redeploy |
| Exposure of public pages | Every page request runs PHP | Static pages are files on a CDN; dynamic routes run Node.js |
| Extensions | Large plugin directory, each plugin runs inside your site | npm packages and integrations, reviewed and versioned in your repo |
| Editing | Familiar admin, Gutenberg or page builders | Structured content models with live preview, depending on the CMS |
| Previewing changes | Built in | Needs setting up, then works per route |
| Performance | Depends on theme, plugins, caching and host | Static generation and image optimization built into Next.js |
| Who can change templates | Admins and theme developers, sometimes editors | Developers, through code review |
| Setup effort | Low | Higher, needs a developer and a build pipeline |
| Migration effort from WordPress | None | Content export, modeling and template rebuild |

## When WordPress is still the right call

WordPress makes sense when:

- Your team knows it well and publishes without friction.
- You are on managed hosting that patches PHP quickly and tells you when it has.
- You rely on plugins that would take real engineering work to replace.
- You do not have a developer and do not plan to hire one.

If that is you, patch PHP, check your plugins and carry on. Moving off WordPress will not help you if your current setup works and your host is on top of it.

## When to move to a headless CMS on Next.js

Move when WordPress is already causing problems, or when nobody can tell you who patches PHP on your site.

- You carry a long plugin list. Each plugin is code running inside your site. Our post on [jumping ship from WordPress](/blog/thinking-of-jumping-ship-from-wordpress) covers plugins and security in more depth.
- You publish to more than one place. Structured content in a headless CMS can feed a website, an app and other channels from one source.
- Uptime and traffic spikes matter to you. When we rebuilt [Tray.ai's site on Next.js and Vercel](/case-study/tray), the static-first approach served traffic through two DDoS waves with 0% downtime. Tray.ai was a Next.js rebuild, not a WordPress migration, but the static-first point carries over.
- Your developers already work in React. A Next.js front end lets them use the tools they know.

> **Next.js development**: We build Next.js sites with a headless CMS, structured content and live preview. [Learn more](/services/nextjs)

## What moving off WordPress looks like

A WordPress migration is mostly content modeling and template work. Exporting the content is the easy part. Our guide on [how to migrate from WordPress to Sanity fast](/blog/how-to-migrate-from-wordpress-to-sanity-fast) walks through exporting your site data as XML and scripting the import. For a broader look at static and headless setups, see [how to transfer from WordPress to Jamstack](/blog/how-to-transfer-from-wordpress-to-jamstack-fast). Our [WordPress to Sanity migration page](/migration/wordpress-to-sanity) covers how the content maps across.

Do it in this order:

1. Patch PHP now. A migration is a project, and PHP2Shell needs fixing this week.
2. Audit what you have, including content types, plugins, forms and redirects.
3. Model the content in the new CMS before you write any templates.
4. Rebuild the templates in Next.js, then move content with a script.
5. Set up redirects from every old URL before you switch over.

## Our take: patch PHP today, then move off the monolith

PHP2Shell is a serious bug in PHP, and every WordPress site on an unpatched PHP version needs fixing now. It does not make WordPress insecure, and Next.js had a CVSS 10.0 bug of its own in 2025. The useful question is who patches your stack and how fast. We're in the time of AI, and it's never been easier to auto-patch this stuff yourself. If the answer for your WordPress site is "our host, within a day," you are in decent shape. If nobody can answer it, find out before you decide anything else. Our [CMS migration service](/services/cms-migration) covers the move to a headless CMS if you make it.

## Frequently asked questions

### What is PHP2Shell?

PHP2Shell is the name for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, published with fixes on October 21, 2026. The PHP security team rates both CVSS v4 9.2. They let an unauthenticated attacker run code on PHP installations that serve web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The earliest affected code path goes back to PHP 5.4.

### Is WordPress affected by PHP2Shell?

WordPress itself has no bug here, but it runs on PHP, so a WordPress site on an unpatched PHP version is exposed. WordPress.org says the vulnerabilities are not specific to WordPress, affect any server that hosts a PHP application, and that no WordPress update is required or planned. The researchers at Calif confirmed pre-authentication remote code execution against specific WordPress versions.

### How do I fix PHP2Shell on a WordPress site?

Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Check your current version in WordPress under Tools, then Site Health, then Info, then Server, or in your hosting panel. On managed hosting, ask your host to confirm the update. If you run PHP 8.1 or older and manage your own server, CISA advises taking PHP-based systems offline until they can be patched or updated.

### Is PHP2Shell being exploited?

Reports differ. On October 21, 2026, CISA said it had not observed exploitation at the time of publication. Amazon Threat Intelligence says it saw an exploitation attempt on October 17 and that PHP2Shell is now being broadly exploited. Treat it as urgent either way and patch.

### Is a headless CMS more secure than WordPress?

Not automatically. Next.js has had critical vulnerabilities too, including CVE-2025-66478, rated CVSS 10.0, which allowed remote code execution in App Router apps. The difference is where the code runs and who patches it. With a hosted headless CMS, the vendor runs the content backend, and your Next.js front end is a dependency you upgrade and redeploy, with statically generated pages served as files.

### Does PHP2Shell affect Next.js sites?

Not directly, because Next.js runs on Node.js, not PHP. None of the Next.js sites we build run PHP, so this flaw does not apply to them. A headless WordPress setup with a Next.js front end still runs WordPress on a PHP server, so that backend needs the PHP update.

### Should I move off WordPress because of PHP2Shell?

Patch PHP first, today. Moving is a project, and PHP2Shell needs fixing this week. After that, our view is that a monolithic system like WordPress puts too much behind one PHP runtime, and we would avoid it. Move if you cannot say who patches PHP on your site and how fast, or if plugin maintenance, editing limits or performance were already slowing you down. If WordPress works for your team and your host patches quickly, staying is a reasonable choice.

### How long does a WordPress to headless CMS migration take?

It depends on content volume, the number of templates and how much custom plugin logic you need to rebuild. Content export and import can be scripted, so the bulk of the work is usually content modeling and rebuilding templates. We cover the process step by step in our guides to moving from WordPress to Sanity and from WordPress to Jamstack.

## Related posts

- [Thinking of jumping ship from WordPress?](/blog/thinking-of-jumping-ship-from-wordpress)
- [How to migrate from WordPress to Sanity fast](/blog/how-to-migrate-from-wordpress-to-sanity-fast)
- [React Server Components CVE-2026-23864: What you need to know](/blog/react-server-components-cve-2026-23864-what-you-need-to-know)

## Related videos

- [Is WordPress safe after PHP2Shell? Our take](/videos/is-wordpress-safe-after-php2shell-our-take)