PHP shipped an emergency security release this week to fix two critical flaws. WordPress itself isn’t broken, but nearly every WordPress site runs on PHP, so nearly every site is exposed until the server’s PHP is patched. For most people, the fix is up to their host.

What happened

On 20 October 2026, the PHP team announced an upcoming security release for two critical vulnerabilities, both rated 9.2 on the CVSS v4.0 scale. Details leaked on social media before the planned disclosure date, so the release was brought forward. Security firm watchTowr confirmed the leaked flaws were real. The fixes landed on 21 October in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. php.announce: [ANNOUNCE] Upcoming Critical PHP Security Release +2

The two vulnerabilities:

• CVE-2026-109618 is remote code execution through memory corruption during out-of-memory handling. europa
• CVE-2026-109619 is remote code execution through stale global state. europa

Both can be exploited without authentication, and proofs of concept have begun circulating, which raises the odds that attackers are already exploiting them. watchTowr has reported exploitation in the wild. europawatchtowr

“Remote code execution” is the worst-case category: an attacker could run their own code on your web server without logging in, then steal data, plant backdoors, inject spam, or take over the site.

Why this matters for WordPress

The bug is below WordPress. According to Codeable’s guide, the flaws are in PHP itself, so updating WordPress, plugins, and themes does not protect you. WordPress.org has said no WordPress update is required or planned. The fix is the PHP update alone. codeable

Almost every site is in scope. Every PHP installation serving web requests is at risk, whether it runs through PHP-FPM, Apache with mod_php, CGI, FrankenPHP or LiteSpeed. The risk is reportedly highest on Apache with mod_php, where an attacker can trigger the flaw before WordPress even loads. codeable

Old PHP versions are a bigger problem. The PHP project only releases fixes for 8.2 and newer. If your site runs PHP 8.1, 8.0, 7.x or older, there is no official fix. Some distributions and paid long-term-support vendors have backported patches, but the real solution is upgrading to a supported version. codeable

What you should do, by hosting type

Managed WordPress hosting (Kinsta, WP Engine, Pressable, Pantheon and similar): You likely need to do nothing. Pressable says all its sites are already protected, and Pantheon has patched all live sites on PHP 8.2 to 8.5. Check your host’s status page or email for confirmation. codeable

Shared hosting: Your host patches PHP for everyone on the server. Watch for their notice, and ask support directly whether they’ve applied the 21 October release. SiteGround, for example, put server-level mitigation in place before the release and then applied the fixes across all its servers. Rollouts differ by provider. Many cPanel shared hosts depend on CloudLinux, which publishes its updated packages after the official release, so the fix can arrive a little later. sitegroundcodeable

VPS or self-managed server: This is the group that has to act today. Nobody will patch it for you. Install the updated PHP packages and restart PHP so every worker runs the fixed version. Package sources have updated at different speeds. Ubuntu’s own packages and Ondřej Surý’s are available, but the volunteer-run Remi repository said it would not have updates immediately. codeable

Behind Cloudflare: Cloudflare has deployed firewall rules against these attacks on every plan with its WAF, including the free one, but it still says customers should update PHP. Treat it as an extra layer, not a fix. codeable

How to check your PHP version

In your WordPress dashboard, go to Tools → Site Health → Info → Server. Note that the number alone can mislead. Many servers install PHP from a Linux distribution, which often applies the fix without changing the version number. An older-looking version doesn’t always mean you’re unpatched, so if in doubt, ask your host. codeable

If you can’t update right away

PHP’s own release notes say there is no complete mitigation and updating is the only safe choice. There are stopgaps for server admins: github

• Setting session.upload_progress.enabled = 0 and restarting PHP blocks one attack path for CVE-2026-109619. WordPress doesn’t use this feature, so a typical site shouldn’t notice. codeable
• Server-level memory and upload-limit changes can narrow CVE-2026-109618 but don’t close it. Leave these to whoever runs your server.

If you manage your own server and truly cannot upgrade, Codeable’s guide notes that WordPress.org and the UK’s NCSC suggest considering taking the site offline until you can.

Upgrading from an old PHP version safely

Old plugins and themes can break on newer PHP, and a broken checkout on a live store costs money. The safe sequence:

1. Take a full backup.
2. Test the new PHP version on a staging copy.
3. Fix whatever breaks.
4. Switch the live site, then check key pages, forms, and checkout.

After patching

Patching closes the door but doesn’t tell you whether someone already walked through. Since exploitation began before the fix, it’s worth reviewing:

• Recently modified files and any unfamiliar PHP files, especially in wp-content/uploads
• Admin user accounts you don’t recognize
• Unexpected redirects or spam content
• Your host’s or a security plugin’s malware scan results

The takeaway

This is a server-level problem with a server-level fix. Your job as a WordPress owner is to find out who patches your PHP, confirm it has happened, and get off any unsupported PHP version. Hosting situations are changing hour by hour, so check your provider’s status page rather than assuming.

Sources: PHP’s announcement, CERT-EU Security Advisory 2026-018, watchTowr’s FAQ, and Codeable’s running WordPress guide, which tracks hosting-provider status. This is a fast-moving situation, so verify current details before acting.