PHP2Shell: what WordPress sites should do, and when to go static

Written by: Altuq CTO · Published: 2026-10-25

PHP2Shell, a pair of flaws in PHP itself disclosed on October 21, 2026, can let an attacker take over the server behind a WordPress site — or any site running on PHP — without logging in. Updating WordPress does not fix it; the PHP version on the server has to be updated. And for companies without a team to keep up with patches, moving to a static site that runs no code on the server removes this whole category of risk.

What PHP2Shell is

PHP2Shell is the nickname for two vulnerabilities found in PHP itself (CVE-2026-109618 and CVE-2026-109619). Both are rated 9.2 out of 10 on the CVSS v4.0 scale, which puts them in the "critical" band. Japan's Information-technology Promotion Agency (IPA), the government body that issues security alerts, warned that exploitation "may allow a remote third party to execute arbitrary code" (IPA, October 22, 2026).

The PHP team released fixes on October 21. What you need to do depends on your PHP version.

The exploitation picture is changing day by day. The day before disclosure, IPA said it had not confirmed any attacks (IPA, October 21, 2026). On October 23, Palo Alto Networks' Unit 42 research team reported real incidents of exploitation (Unit 42). Expect attacks to increase the longer a server stays unpatched.

What it means for WordPress sites

WordPress runs on PHP, so it is directly exposed. The key point: updating WordPress or its plugins does not fix this vulnerability. The fix has to happen in the PHP installation on the server that runs WordPress.

On shared hosting, updating PHP is usually the hosting provider's job. Most providers are rolling out fixes, but on services where each site picks its own PHP version, a site left on an old version may not get the fix.

The most serious cases are sites still on PHP versions that are no longer supported. Of roughly 1.5 million internet-facing PHP servers that reveal their version, 59% run a branch that will get no official fix, according to an analysis by CybelAngel of Shodan data from October 20. Japan has the third-highest number of these servers in the world.

This is the third serious WordPress-related vulnerability in four months:

• July: "wp2shell," a flaw in WordPress core that can allow remote code execution without logging in. IPA issued an urgent alert (IPA, July 22, 2026).
• Early October: a flaw rated 10.0, the maximum, in the popular Bricksforge plugin, with attacks observed (The Hacker News).
• October 21: PHP2Shell, in PHP itself.

In four months, all three layers WordPress depends on — the core, its plugins, and PHP — have had critical problems.

Three things to do today

1. Check your PHP version and update to a fixed release. Find the PHP version in your hosting control panel and confirm it is at or above the fixed release in the table above. If you're not sure, check your hosting provider's announcements or ask whoever maintains your site.
2. If you're on PHP 8.1 or older, plan a move now. There will be no official fix. IPA advises restricting access if you can't patch, and, depending on the impact, considering taking the service offline.
3. Check for signs of intrusion and change passwords. Look for administrator accounts, files or plugins you don't recognize. If someone did get in, passwords and API keys stored on the server may have been stolen, so changing them is a sensible precaution.

Why this keeps happening with WordPress

Every time a page is viewed, WordPress runs PHP code and a database query on a public server to assemble the HTML. That makes it flexible, but it also means there is always a program listening to requests from the internet. A vulnerability anywhere in PHP, WordPress core, the theme or a plugin becomes a way in.

WordPress's popularity — it runs about 40% of all websites — also makes it attractive to attackers: one working exploit can be aimed at huge numbers of sites automatically. Running a WordPress site therefore becomes a race to finish updating before attacks spread, every time a new vulnerability is announced. A company with a dedicated web team can keep up. A company that manages its site alongside its actual business often can't.

What a static site with a headless CMS is — and why it's safer

A static site is a website made of HTML files that are generated in advance and served as they are. Because no program runs when someone views a page, there is nothing on the public site for a server-side flaw like PHP2Shell to attack.

How do you update content, then? With a headless CMS: a content management system that separates the editing interface from the way the site is displayed. Sanity is one widely used example. Editors write and publish in Sanity, and the static HTML is rebuilt and published automatically from that content.

This site, corp.altuq.com, is built exactly this way. We edit articles and company information in Sanity, and the public site is plain static HTML with no server-side code at all. It loads no JavaScript either: as of October 2026, every page and image together comes to about 224 KB. Structured data and an AI-readable summary (llms.txt) are generated automatically from the same Sanity content, so search engines and AI assistants can read our company information correctly. It's not just more secure — it's an "AI-native" corporate site, built for a world where people increasingly find information through AI.

That doesn't mean a static site has zero risk. If someone takes over your Sanity account, they can change your content, so two-factor authentication is essential. Third-party services such as contact forms, and the accounts for your domain and hosting, still need care. And you are relying on Sanity, an outside service, for the editing side — something to weigh consciously.

Which sites should move — and which shouldn't

A static site is not the right answer for every WordPress site. The fit is clear-cut:

Sites whose job is to publish information gain the most from going static. For sites like those in the right-hand column, the realistic options are to stay on WordPress and keep it rigorously patched and protected, or to move to a managed service that handles maintenance for you.

How a migration works, and how Altuq can help

Moving from WordPress to a static site usually follows these steps:

1. Inventory: list everything to move — pages, posts, images, contact forms.
2. Design: decide what editors will manage in Sanity (posts, company information and so on) and the site design.
3. Migrate and build: move the content and build the static site.
4. Keep your URLs: keep existing URLs, or set up 301 redirects to new ones, to protect your search rankings.
5. Launch and hand over: train editors on the new workflow and shut down the old server.

Drawing on what we learned building this site, Altuq has started helping companies move their existing corporate websites to more secure, AI-native ones. If you're unsure whether staying on WordPress is safe, or want to stop spending time on updates, please get in touch. You can read more about us on our company page.