php2shell: What the Critical PHP Flaws Mean for WordPress — and Why a Static Front End Helps

Published October 22, 2026, from the PHP Foundation, CISA and Rapid7 advisories. We will update this page as the situation changes.

Short version: update PHP now — that is the fix, and nothing on this page replaces it. A static front end does not remove PHP from your WordPress server, but it means ordinary visitors never touch PHP, so the server that does run PHP can be kept small, hidden and even switched off for a while without taking your site down.

What happened

• Two flaws, CVE-2026-109618 and CVE-2026-109619 (nicknamed “php2shell”), let an unauthenticated attacker execute code on servers running PHP under the right conditions. Both are rated CVSS 9.2.
• CVE-2026-109618 corrupts memory when a request runs out of memory at the wrong moment. On Apache with mod_php it can be triggered before any application code runs — so it does not matter which CMS or plugins you use — and full code execution was shown with default settings. It was also confirmed on PHP-FPM through application code paths.
• CVE-2026-109619 is a use-after-free caused by state left over from a previous request; code execution was demonstrated against a real application on Apache with mod_php.
• Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released October 21, 2026. CISA says the flaws affect all PHP installations serving web requests and recommends patching immediately, starting with internet-facing systems.
• Exploitation: at release, neither the PHP security team nor CISA had seen working exploits in the wild. But details leaked two days early, a proof-of-concept video circulated, and researchers expect exploit code to become public soon.

First: patch

Your PHP branch	Update to	Note
8.5	8.5.12 or newer
8.4	8.4.27 or newer
8.3	8.3.36 or newer
8.2	8.2.35 or newer
8.1 or older	Upgrade to a supported branch	No fix; CISA advises taking such systems offline until upgraded

In WordPress, see your version under Tools → Site Health → Info → Server → PHP version. On managed or shared hosting, ask your host whether the update is applied — many patched ahead of the release. On your own server, update the PHP packages and restart PHP-FPM or Apache. Do every site that runs PHP: staging copies, old installs and tools such as phpMyAdmin count too.

Why WordPress sites are so exposed

A normal WordPress site runs PHP for every single page view: each visitor, bot and scanner that requests a page reaches PHP. Mass-scanning the internet for vulnerable servers is cheap, and a flaw that triggers before application code runs does not care how well you maintain your plugins. Whoever can send a request to your PHP can try the attack.

What a static front end changes

	Normal WordPress	Static copy on a CDN
Page views run PHP	Every one	None — pages are plain files
Who can reach PHP	Anyone who loads a page	Only what you allow: you in wp-admin, and live features if you use them
Where WordPress lives	On your public domain	Can sit on a separate address, locked to Cloudflare or to you
If you must take PHP offline	The site is down	Visitors keep getting pages; editing and live features pause

That last row matters right now. CISA’s advice for systems that cannot be patched immediately is to take them offline. With a static copy, you can stop WordPress — or block its server at the firewall — while you update, and visitors keep reading your site from the CDN.

What it does not change

• WordPress still runs PHP, so it still needs this update. Static is defense in depth, not a patch.
• Live features still reach WordPress. If your static copy sends comments, search, forms or WooCommerce prices to WordPress’s REST API, those requests run PHP. So does wp-admin if it is reachable on your domain.
• A hidden server is only hidden if nothing points to it. Old DNS records, the server’s IP in email headers or a forgotten subdomain can reveal it.

Lock it down this week

1. Update PHP on every server that runs it, and confirm the version in Site Health.
2. Put wp-admin behind a login gate, for example Cloudflare Access (free for small teams), so only you can reach it.
3. Let only Cloudflare reach the origin: allow Cloudflare’s IP ranges at the server firewall and drop the rest, or use Cloudflare Tunnel.
4. Turn on a WAF; CISA notes it may provide some protection until systems are patched.
5. Watch for warning signs such as PHP processes starting shells or downloading files, as CISA recommends.
6. Serve visitors a static copy, so the public site does not depend on PHP at all.

Where Pinery Static fits

Pinery Static exports your WordPress site to plain HTML and deploys it to Cloudflare Pages: the public site becomes files on a global CDN, and WordPress becomes the place you edit. The free plan does the full export and deploy; Pro keeps comments, search, forms and WooCommerce prices working through WordPress’s REST API, and its domain switch serves the static site on your existing domain while wp-admin keeps working. On our demo shop, the static copy loads in 0.09 s versus 1.6 s for WordPress (median of 27 locations) — see the measurements. And please: update PHP first.

Frequently asked questions

Is my WordPress site affected?

If it runs on PHP 8.2–8.5 below the fixed releases, assume yes until you update. Sites on Apache with mod_php are the most exposed, because the first flaw can be triggered before WordPress runs.

Does a static site make updating PHP unnecessary?

No. Your WordPress server still runs PHP and must be updated. A static front end reduces who can reach it and lets you take it offline safely, but it is not a patch.

My host manages PHP for me. Do I need to do anything?

Check the PHP version under Tools → Site Health → Info → Server, or ask your host. Many hosts patched quickly, but confirm it — and check any other sites or staging copies you run elsewhere.

Can I keep comments and forms on a static site?

Yes, by sending them to WordPress’s REST API (Pinery Static Pro does this). Those requests do reach PHP, so keep WordPress updated and protected even when visitors browse a static copy.

Is there a workaround if I cannot update today?

CISA mentions only two interim measures: a web application firewall, which may give some protection, and taking unpatched PHP systems offline. A static copy makes the second option possible without downtime for readers.

Sources

• PHP Foundation — Today’s PHP security release (October 21, 2026)
• CISA — Critical vulnerabilities in PHP require immediate patching
• Rapid7 — CVE-2026-109618 and CVE-2026-109619: critical unauthenticated RCE in PHP
• Infosecurity Magazine — Critical PHP vulnerabilities leaked ahead of scheduled patch