October 26, 2026
Kausar
On 21 October 2026 the PHP project shipped emergency releases for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which researchers named php2shell. Both are rated CVSS 9.2 and can allow unauthenticated remote code execution. The bugs sit in the PHP runtime itself, in how PHP cleans up after out-of-memory and other fatal errors. They are not WordPress bugs. Wiz demonstrated the exploit against the stock WordPress, Drupal and Joomla container images because those are popular PHP apps, and their write-up is clear that the vulnerable code is in PHP.
Many site owners missed this in the first few days: updating WordPress core, your plugins or your theme does not fix php2shell. The fix is to upgrade PHP on the server to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, then restart every PHP worker. If your host still runs PHP 8.1 or older, the PHP project no longer ships fixes for it, so you need your host's backported package or an upgrade to a supported branch.
If you run WordPress, do that first. Ask your host which PHP version serves your site today, and get it patched this week. Cloudflare and other WAF providers pushed rules that block known exploit attempts, and those help, but the PHP advisory and Cloudflare both say patching is still required.
php2shell also left a lot of founders and marketing leads asking why their marketing site runs a full server-side language on every request when most pages look the same to every visitor. For many B2B SaaS sites the answer is "because that is how WordPress works," and after a week of emergency patching it is fair to look at other options.
Below we cover where WordPress gets expensive for marketing and SaaS teams, what changes with a mostly static Next.js site, when to stay on WordPress, and the migration steps we follow at StaticMania. The checklist at the end also comes as a longer PDF.
Want the full checklist as a PDF, with a decision tree for whether to migrate at all?
WordPress is a good CMS. It runs a huge share of the web, editors know it, and the plugin directory has an answer for almost anything. The costs below show up over time, mostly on sites that started simple and grew.
A typical WordPress install is PHP, a MySQL or MariaDB database, the WordPress core, a theme, and somewhere between ten and forty plugins, all reachable from the public internet on every request. Each of those layers has its own update cycle. php2shell showed that even a fully updated WordPress can be exposed through the runtime underneath it. Most reported WordPress vulnerabilities are in plugins and themes, and the login and XML-RPC endpoints draw constant automated traffic.
A well-run WordPress site with managed hosting, a WAF, few plugins and fast patching is in decent shape. Someone still has to do that work every month, for a marketing site that mostly serves the same HTML to everyone.
Most WordPress sites add features through plugins, and each one adds weight. A page builder, an SEO plugin, a forms plugin, a cache plugin, two analytics snippets, a popup tool and a slider each add scripts, database queries and their own settings screens. A few years in, nobody remembers which plugin outputs which piece of markup, and updates become a risk because one of them might break the layout. Teams start avoiding updates, which brings the security problem back.
WordPress can be fast. Getting there usually means a caching plugin, a CDN, image optimization, and careful theme work, and keeping it there means checking Core Web Vitals after every new plugin or design change. Page builders in particular tend to ship heavy CSS and JavaScript. For SaaS marketing sites where ad spend lands on these pages, slow LCP and layout shift cost real money in conversion rates.
You need PHP, a database, backups, staging, and a plan for traffic spikes. Managed WordPress hosts handle much of this for a monthly fee. Self-hosted setups need someone who knows how to patch PHP at short notice, which is exactly what php2shell asked of everyone last week.
If your product is built in React and TypeScript, a marketing site in PHP templates sits apart from everything else the team ships. Designers end up rebuilding the same components twice, and marketing waits on whoever still knows the theme. That gap is easy to live with until you want shared components, a pricing page that reads from your billing system, or docs that match the product.
Next.js is a React framework that can render pages at build time, on the server per request, or in a mix of both. For a marketing site, most pages can be pre-rendered as static HTML and served from a CDN, with content pulled from a headless CMS such as Prismic, Sanity, Contentful or Storyblok.
When a page is pre-rendered, a visitor gets a file from a CDN edge close to them. There is no PHP process or database query on that request. Next.js can also regenerate individual pages in the background when content changes (incremental static regeneration, or on-demand revalidation from a CMS webhook), so editors do not have to wait for a full rebuild.
In practice this usually means fast first loads and steady Core Web Vitals without a caching plugin. You still have to build it well. Heavy client-side JavaScript or oversized images will slow a Next.js site down just as they slow WordPress.
In a headless setup, the CMS lives on the vendor's infrastructure or behind its own login, and the public site is mostly static files plus a few server routes for things like forms. There is no public wp-admin, no plugin code running on page views, and no PHP runtime on the marketing site at all.
That reduces what is exposed, though the site can still be attacked. A Next.js site still has dependencies to update, server routes and API keys to protect, a CMS account to secure with SSO or 2FA, and its own framework vulnerabilities from time to time. Next.js has shipped security fixes of its own, and you need to apply them just as you patch PHP. The upkeep is smaller, and it still has to happen.
Your marketing site can use the same React components, TypeScript setup and design system as your app, with Git-based reviews and a preview deployment for every pull request. For SaaS companies this is often the main reason to move, because the marketing site stops being a codebase nobody on the product team wants to touch.
You will lose some things, at least at first:
We build Next.js sites for a living, and we still tell some teams to stay on WordPress. Here are the cases where we usually do.
You only need to patch PHP and harden what you have. If the site works, the team likes it, and the real problem was an unpatched server, fix that. Upgrade PHP to a patched release, cut plugins you do not use, put a WAF in front, turn on automatic minor updates, and move to a managed host if patching is a struggle. That is cheaper than a migration and solves the immediate risk.
Your store runs on WooCommerce with complex logic. Subscriptions, custom checkout rules, B2B pricing, ERP integrations and years of order history are hard to move. Headless commerce exists, but if commerce is the business and WooCommerce works, a migration has to be justified on more than speed and security.
Your editors depend on a page builder and nobody can support a new stack. If a non-technical team builds landing pages in Elementor every week and there is no developer on hand, a Next.js site with a fixed block library can slow them down. This can be solved with a good slice library and visual editing, but plan and budget for it honestly.
The budget is not there. A careful migration of a marketing site with a blog is a multi-week project. If the money would leave the site half-finished, patch and harden now and plan the migration for next year.
There is also a middle path. You can keep WordPress as the editing backend and build the front end in Next.js using the WordPress REST API or WPGraphQL. That keeps the editor experience and removes PHP from the public site, though WordPress still needs patching wherever it runs. It is a reasonable step for teams with years of content and editors who do not want to switch.
Not sure which side of the line your site is on? The PDF has a one-page decision tree to work through with your team.
This is the process we follow for marketing sites and content-heavy blogs. You can swap tools at any step, but skipping a step usually shows up later as lost traffic or rework.
The output is a spreadsheet of URLs with a decision for each one: keep, merge, redirect or retire.
Decide how content will be structured in the new CMS before anyone writes code.
Build the component library once, in code, so pages are assembled from parts.
If your product already has a design system, reuse it here. That is one of the main payoffs of moving to Next.js.
This is where migrations lose traffic, so give it real time.
Use this as a working list. The downloadable PDF has the same items plus a decision tree for whether to migrate at all.
Before you decide:
Discovery:
Content model and design:
Build:
SEO and launch:
No. php2shell (CVE-2026-109618 and CVE-2026-109619) is a vulnerability in the PHP runtime. Updating WordPress core, plugins or themes does not change the PHP version on your server. You need to upgrade PHP to 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later and restart PHP workers, or ask your host to confirm they have done it.
Patch PHP first. That is the immediate fix, and it applies whether or not you ever migrate. A migration to Next.js is a longer-term decision about maintenance, performance and how your team works. It makes sense to review that decision now and then plan any move on a normal project timeline.
It can if redirects and metadata are handled badly. With a complete URL inventory, one-step 301 or 308 redirects for every changed URL, carried-over titles and meta descriptions, and a fresh sitemap submitted in Search Console, most sites keep their rankings. Expect some movement in the first few weeks and track your top pages weekly.
Yes. Headless WordPress uses the REST API or WPGraphQL to feed content to a Next.js front end. Editors keep the WordPress admin, and visitors never hit PHP directly. WordPress still runs on PHP behind the scenes, so it still needs patching, preferably on a host that is not publicly reachable except for editors.
It depends on page count, how much custom functionality the plugins provided, and how much content needs rework. A small marketing site moves faster than a content-heavy blog with hundreds of posts and custom post types. Discovery is the best way to get a reliable estimate, because it shows the number of templates, blocks and redirects involved.
Prismic, Sanity, Contentful, Storyblok and headless WordPress all work well with Next.js. The choice depends on your editors, budget and content model more than on the framework. We compared three of them in detail in our Sanity vs Contentful vs Storyblok guide.
It is more contained than a typical WordPress install because public pages are mostly static and there is no PHP or plugin code on the request path. It still needs care: keep Next.js and npm dependencies updated, protect API routes and environment variables, and secure your CMS accounts with SSO or 2FA.
If you are weighing a migration, start with the checklist. The PDF version adds a one-page decision tree, a redirect-pattern list for WordPress URLs, and a launch-week QA sheet.
When you want a second opinion, StaticMania builds Next.js and headless CMS sites for B2B SaaS teams in the US and Europe. We can review your current WordPress setup, tell you honestly whether a migration makes sense, and give you a scoped plan if it does.
Get the WordPress to Next.js checklist, or talk to us about your site.
