Critical PHP security vulnerabilities, October 2026: what WordPress site owners need to know

On 20 October 2026 the PHP security team published an advance notice of a critical security release. PHP is the language WordPress runs on, along with Drupal, Joomla, Magento, Laravel and a large share of the web, so this concerns most business websites, whether or not anyone on the team has heard of PHP. Here is what was announced, what it means for a site owner, and what to do about it.

What was announced

The notice, titled Upcoming Critical PHP Security Release, says the release will fix two critical vulnerabilities, each rated 9.2 on the CVSS v4.0 scale. It is scheduled for Wednesday 21 October 2026 at 14:00 UTC, which is 10 a.m. Eastern, and the team said it would ship earlier if details became public or active exploitation was seen. The affected and fixed versions are to be published with the release. No workaround was offered; the fix is to upgrade.

The UK's National Cyber Security Centre issued its own guidance on 21 October. It advises organisations to identify every system running any version of PHP, prioritising internet-facing systems, to monitor them for malicious activity, to apply PHP updates as they become available, and, where immediate remediation is not feasible, to consider taking the system offline until it can be fully mitigated.

Trade press has reported that technical details leaked before the release and that some hosts have seen exploitation attempts. PHP's own notice does not confirm those reports. Treat them as unverified until the release notes are published, and treat the release itself as urgent either way.

What this means if your site runs WordPress

Three things are worth being precise about, because the commentary around events like this tends to blur them.

• PHP is not updated from the WordPress dashboard. WordPress core, themes and plugins update from inside WordPress. PHP runs on the server, and WordPress's own guidance is that you update it through your hosting provider, either in the host's control panel or by asking them to do it. If you do not know who hosts your site, that is the first thing to find out.
• Not every installation is necessarily exploitable. Until PHP publishes the affected versions, nobody can say which sites are exposed. Anyone claiming to have confirmed your exposure from your public URL alone is guessing: a page does not reveal its PHP version or patch status without server access.
• Old PHP is the real risk. WordPress recommends PHP 8.3 or higher. Versions before 8.x are past end of life and may receive no fix at all. You can see your version under Tools, Site Health, Info, in the Server section.

What to do today

1. Find out who hosts the site and which PHP version it runs.
2. Ask the host, in writing, when the patched PHP release will be applied to your server. Managed hosts generally do this for you; on a VPS or dedicated server it is your job or your developer's.
3. Take a full backup before any update, and update WordPress, themes and plugins while you are at it.
4. Watch the site after the update: forms, checkout, logins and anything a plugin depends on.
5. If the server cannot be patched promptly, follow the NCSC's advice and weigh taking it offline against the risk of leaving it exposed.

None of this requires a new website. Patching comes first. A rebuild is never a substitute for applying the update.

When a rebuild is justified

The advisory is a good moment to ask a different question: how much software are you running just to show visitors a handful of pages? A typical small-business WordPress site runs a web server, a PHP runtime, a database, a theme and twenty or thirty plugins, each of which needs updates and any of which can break the others. Most of that exists to serve pages that do not change from one visitor to the next.

For those sites, static architecture is the better business decision. The pages are rendered ahead of time and served as plain files, so there is no PHP application or database behind the public site to patch, and nothing to slow down between updates. We wrote about our own move in Why we moved on from WordPress. A rebuild is justified when the maintenance burden, the speed, or the conversion rate of the current site is costing you more than the migration would. It is not justified simply because a vulnerability was announced, and if you run a complex store, a membership system or integrations that depend on specific plugins, staying on a well-maintained WordPress may be the right answer.

How a migration protects your search traffic

The fear that stops most businesses from migrating is losing rankings. That fear is reasonable, and the remedy is well documented. Google's guidance for a site move with URL changes comes down to a short list: inventory the old URLs, starting with the ones that carry traffic and links; map each one to its new address; use permanent server-side redirects straight to the final page; update internal links and canonicals; submit a new sitemap; and monitor indexing and traffic afterwards. Google asks that redirects stay in place for at least a year. In our migrations each of those steps is a deliverable with a checklist behind it, not a hope.

What we can and cannot tell from the outside

From a public URL we can measure speed, Core Web Vitals, page structure, indexing and how the site converts. We cannot see your PHP version, your patch status or your hosting arrangement without your help. That is why our website modernization assessment is a conversation about your site, your traffic and your maintenance burden, and ends with a recommendation that may well be to stay where you are and tidy up.

Status of this advisory

Last checked 21 October 2026, before the scheduled release. Once PHP publishes the affected and fixed versions we will update this section with the version numbers and what they mean for common hosting setups.