PHP2Shell is the case for not building your next site on WordPress
PHP2Shell exposed the real weakness of WordPress hosting: the site owner cannot fix the layer that broke. Here is how Rune builds and runs sites so that a critical patch is an afternoon, not a support ticket.
- Published
- Reading time
- 7 min read
Written for: Business owners choosing how to build their next site, and agencies responsible for a fleet of them.
On October 21, 2026 the PHP project shipped emergency fixes for two critical bugs, nicknamed PHP2Shell, that let an attacker run code on a server without logging in. The researchers proved it against a stock WordPress install. If you own a WordPress site, our what-to-do guide is the page to read first. This one is about the question that comes after: why does a bug like this turn into weeks of worry for a WordPress owner, and what would have to be different for it not to?
What happened, briefly
Wiz Research, working with OpenAI, Calif, and Google, found a family of memory-safety bugs in how PHP recovers from running out of memory during a request. Chained together, they give unauthenticated remote code execution and let an attacker read live memory from the PHP worker, including other people's passwords and tokens. The pair is tracked as CVE-2026-109618 and CVE-2026-109619, rated 9.2 of 10. Every PHP version back to 5.4 is affected. Fixed releases are 8.2.35, 8.3.36, 8.4.27, and 8.5.12; PHP 8.1 and older get nothing upstream.
The detail that matters for this article: WordPress did not write the bug, and WordPress cannot fix it. Neither can a plugin. The fix is a new PHP build on the server, and on nearly all WordPress hosting, the server belongs to someone else.
The problem is not the bug. It is who can fix it.
Every piece of software has critical bugs eventually. Node.js has had them, Linux has had them, the frameworks we use have had them. What decides whether a bug is a bad afternoon or a bad month is how many parties sit between you and the patch, and whether any of them are waiting on each other.
A typical small business WordPress site has this chain: the owner, who can click Update on plugins; the freelancer or agency who built it, who can edit the theme; the hosting company, who runs PHP; and the hosting company's upstream (cPanel, a Linux distribution, a container vendor), who builds the PHP packages. On October 21 the first two had nothing to click. The only useful action was opening a ticket with the third and waiting for the fourth. Many hosts responded quickly and well. Many others answered with "we have added firewall protection", which is a stopgap and not a fix, and some PHP 8.1 customers have no fix coming at all.
That is the structural weakness. The part of a WordPress site that the owner controls (plugins, theme, core) is not the part that broke. The part that broke is the part they cannot touch.
How a Rune site is built so that the chain is one link
We build on a different stack, but the stack is the smaller point. The bigger one is that we own every layer of it, from the runtime version to the edge, and we run every site we have ever built through one process. Concretely:
- No PHP. Sites are built in Next.js on Node.js, so PHP2Shell does not apply to anything we run. We are not claiming Node is bug-free; it is not. We are claiming the next point.
- Every site is a container image. The runtime version is a line in a Dockerfile that we wrote. Patching the runtime means changing that line, rebuilding, and shipping. There is no host to email, because we are the host.
- One codebase for the whole fleet. Every site we run lives in a single monorepo managed with Turborepo. A security update to a shared dependency lands once, in one commit, and every site rebuilds from it. We patched the entire fleet to a new Next.js release for a security advisory this week in a single change. We did not patch thirty sites thirty times.
- Kubernetes rollouts with rollback. New versions come up alongside the old, get health-checked, and take traffic only when they pass. If something is wrong, rolling back is one command. Nobody is editing files on a live server over FTP.
- No plugin marketplace. A typical WordPress site carries twenty or thirty plugins, each written by someone else, each an update chore and an attack surface. On our sites, the features are code we wrote and the content lives in Skal, our own CMS, in a database you own. There is nothing to abandon and nothing to fall behind.
- The edge is ours too. Every site sits behind Cloudflare, with TLS certificates issued and renewed automatically. If a vulnerability ever needed a request-blocking rule while a patch was built, it would be applied fleet-wide in minutes.
The result is that when the next critical advisory lands, whatever layer it hits, the person who reads it is the person who can fix it, and the fix reaches every site at once.
The same week, side by side
| WordPress on shared hosting | A site on our process | |
|---|---|---|
| Who can apply the fix | The hosting company, on their schedule | Us, the same day |
| What the owner has to do | Check Site Health, open a ticket, follow up, verify | Nothing |
| Sites patched per action | One host at a time, one ticket each | The whole fleet, one commit |
| Interim protection | Depends on the host and the plan | Edge rule applied fleet-wide |
| If the patch breaks something | Restore from backup, if there is one | Roll back with one command |
| Plugins to check afterward | Twenty to thirty, each with its own author | None |
What this is not
This is not "WordPress is bad". WordPress is a reasonable choice for someone who wants to build and maintain a site themselves with no developer involved, and a good managed host narrows the gap considerably. The argument is narrower: if you are paying a professional to build your site anyway, you should get a build where that professional can also patch the runtime, the server, and the edge, and can do it for every site they run in one motion. That is what you are actually buying when you buy a site from an engineer instead of a template.
If you are on WordPress today
There are two honest paths, and we offer both.
Fix what you have. We will check which PHP actually serves your site, handle the host conversation, apply the interim hardening, sweep for compromise, and give you a written summary. If you are an agency with a list of client sites, we run that as a batch and can do it under your name through our white-label service. The steps are laid out in the PHP2Shell guide if you would rather do them yourself.
Or stop having this problem. A rebuild on our process gives you a custom site with Skal for editing your own pages, hosted and maintained by us under a care plan, with the runtime, the servers, and the edge in one set of hands. For anything bigger than a marketing site, the same process carries custom software and web apps. Agencies get the same thing for every client site, which is the real pitch: a single upgrade path for the whole fleet.
Either way, you will hear back from the engineer who does the work. Use the contact form or call, and tell us what you are running.
Questions people ask
Are sites built by Rune affected by PHP2Shell?
No. Nothing we build or host runs PHP. Our sites run on Node.js and Next.js, in containers we build, on infrastructure we operate. That does not make them immune to every future vulnerability, but it means we can patch any layer ourselves, fleet-wide, the day an advisory lands.
Can you fix my existing WordPress site instead of rebuilding it?
Yes. We will confirm the PHP version actually serving the site, work the host ticket, apply interim hardening, check for compromise, and rotate secrets if needed. We will also tell you plainly if the site has enough accumulated problems that a rebuild would cost about the same.
Do I lose the ability to edit my own pages if I leave WordPress?
No. Our sites ship with Skal, a visual editor on a live canvas. You edit text and photos in place, add pages, and publish, without a developer and without a plugin ecosystem underneath.
My agency manages dozens of client WordPress sites. What do you offer?
Two things. A batch PHP2Shell response across your client list, done under your brand through our white-label service. And, for new builds, a process where every client site shares one codebase and one upgrade path, so the next critical advisory is one change for the whole fleet.
Who owns the site if you build and host it?
You do. The code, the content, and the database are yours, and if you ever leave our care plan we hand over a deployable build.