Web Development

Critical PHP Security Update (CVE-2026-109618): What WordPress Site Owners Must Do Now

Web Brick Studio · · 8 min read

Critical PHP Security Update (CVE-2026-109618): What WordPress Site Owners Must Do Now

On October 21, 2026, the PHP project shipped emergency releases for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 out of 10 and, according to PHP, they can allow unauthenticated remote code execution. In plain words: someone who has never logged in to your site could run their own code on your server.

If you run a WordPress or WooCommerce website, this one matters more than the usual plugin update. The problem is not in WordPress at all. It sits one layer below, in the language WordPress is written in. That means every PHP site is in scope, whether it is a five page brochure site in Texas, a WooCommerce shop in Manchester or a membership site in Melbourne.

This guide explains what happened, how to check whether your site is exposed and exactly who needs to do what, depending on where your website is hosted.

What happened on October 21

The PHP team released fixed versions for every branch it still supports: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Every version released before those is affected. PHP 8.1 and older are affected too, and the PHP project no longer publishes updates for them, so they only get a fix if your host or Linux vendor adds one.

Attackers did not wait. Cloudflare’s CEO reported thousands of exploit attempts before the public announcement, hundreds of thousands within two hours of it, and millions by the following day. That pattern is typical of serious server bugs now. Automated scanners, many of them driven by AI agents, start probing the internet within minutes.

WordPress.org has been clear that no WordPress update is required or planned. WooCommerce published the same message for store owners. The fix is the PHP update alone.

Who is most at risk

Security write ups point to servers running Apache with mod_php as the highest risk setup, because an attacker can trigger the flaw before WordPress even loads. That means a security plugin inside WordPress cannot see or stop the attack. Sites on PHP-FPM are still affected and still need the patch, but the mod_php setups are the ones to fix first.

You are also in a higher risk group if any of these sound familiar:

  • You run your own VPS or cloud server and nobody has logged in to update packages for a while.
  • Your site is still on PHP 8.1, 8.0 or 7.4 because an old theme or plugin breaks on newer versions.
  • You use a server panel such as Laravel Forge, Ploi or RunCloud, where you are responsible for PHP updates yourself.
  • Your web server can be reached directly by its IP address, which lets attackers skip your CDN or firewall.

How to check your PHP version in WordPress

This takes about thirty seconds:

  1. Log in to your WordPress dashboard.
  2. Go to Tools, then Site Health.
  3. Open the Info tab and expand the Server section.
  4. Look at the PHP version line.

If you see 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later on the same branch, you are on a patched release. If you see something older, do not panic straight away. Linux distributions such as Ubuntu and Debian often backport security fixes without changing the version number, so an older looking number is not proof that you are unpatched. The only reliable answer comes from your host, so ask them directly whether the October 21 fix has been applied.

What to do based on your hosting type

Managed WordPress hosting

If you use a managed host, your host is responsible for patching PHP. As of October 22, Pressable, Pantheon, BigScoots, SpinupWP, OVHcloud, Netcup and Plesk had reported patched or protected servers. WordPress.com, WordPress VIP and WP Cloud were protected from the start. SiteGround, WP Engine, Flywheel, DreamHost and Namecheap reported firewall level protection with patches rolling out, and Kinsta, Liquid Web, Rocket.net and Cloudways were working through their fleets. Check your host’s status page or support inbox and get written confirmation.

Shared hosting

On shared hosting, PHP is patched for everyone on the server at once. You usually cannot do it yourself. Watch for notices from your host, and if your account is pinned to PHP 8.1 or older, switch to a supported version in your control panel after you have tested it. Hostinger, GoDaddy and similar hosts let you change the PHP version per site. GoDaddy customers in particular were advised to confirm status with support.

VPS and self-managed servers

This is where you must act today. If you are on DigitalOcean, Linode, AWS, Hetzner, Vultr or a similar provider, nobody is patching for you. Install the updated PHP packages from your usual source, such as Ubuntu’s own repositories or the sury.org packages, and then restart PHP so every worker process runs the fixed version. Updating the package without restarting PHP-FPM or Apache leaves the old code running in memory.

Laravel Forge users need to update PHP themselves. RunCloud scheduled patches for NGINX servers but does not manage OpenLiteSpeed updates, so check which stack you are on.

If you cannot update PHP today

Sometimes a patch has to wait a few hours. PHP’s announcement lists interim steps for server administrators only:

  • Set session.upload_progress.enabled = 0 in php.ini and restart PHP. This blocks one attack path for CVE-2026-109619, and WordPress does not use this feature, so nothing on your site should break.
  • Tighten memory and upload limits as described in PHP’s advisory. This narrows CVE-2026-109618 but does not close it.

These steps reduce risk. They do not make a server safe. If you are on PHP 8.1 or older and cannot upgrade quickly, WordPress.org and the UK’s National Cyber Security Centre both suggest taking a self-managed site offline until it is fixed. That sounds dramatic, but an hour of downtime is cheaper than cleaning up a hacked server and notifying customers.

Does Cloudflare protect me?

Partly. Cloudflare deployed firewall rules for this issue on every plan, including the free one. If you are on Pro, Business or Enterprise, open your managed rules and make sure they are set to block, not just log. But treat this as a seat belt, not a fix. Attackers can sometimes reach your server directly by IP address and skip Cloudflare entirely. Patching PHP is still the job.

Upgrading from PHP 8.1 or older safely

Many small business sites are stuck on old PHP because of an old theme or an abandoned plugin. If that is you, this is the push to fix it properly:

  1. Take a full backup of files and database, and store it off the server.
  2. Create a staging copy of the site. Most hosts offer one click staging.
  3. Switch staging to PHP 8.3. WooCommerce now recommends 8.3 or newer.
  4. Click through key pages: home, contact form, checkout, account pages and anything built with Elementor or another builder.
  5. Turn on debug logging and look for fatal errors and deprecation warnings.
  6. Replace or update anything that breaks. Abandoned plugins are a security risk on their own.
  7. Push the change live during a quiet period and test again.

If your site has not been touched in a while, a performance pass is worth doing at the same time. Our guide on how to speed up a WordPress website covers quick wins that pair well with a PHP upgrade.

What this means for businesses in the US, UK and Australia

United States: Many US small businesses run WooCommerce on budget VPS plans set up years ago by a freelancer who has moved on. Those are the servers most likely to still be unpatched. If you take card payments, a breach can also trigger PCI questions from your payment processor.

United Kingdom: The NCSC has backed the advice to take unpatchable sites offline. If customer data is exposed, UK GDPR may require you to report a breach to the ICO within 72 hours of becoming aware of it, so fixing it now is far easier than explaining it later.

Australia: Australian businesses covered by the Notifiable Data Breaches scheme may need to tell the OAIC and affected customers if a breach is likely to cause serious harm. Hosting a site on an overseas VPS does not change who is responsible for it.

A quick checklist

  • Check your PHP version in Site Health.
  • Ask your host in writing whether the October 21 PHP fix is applied.
  • If you manage your own server, update PHP and restart it today.
  • Move off PHP 8.1 or older, testing on staging first.
  • Set Cloudflare managed rules to block, if you use it.
  • Review access logs for odd requests from October 20 onwards.

Sources

Need a hand with this on your own site? See our WordPress development and SEO services services.

Frequently asked questions

Do I need to update WordPress to fix CVE-2026-109618?

No. WordPress.org says no WordPress update is required or planned. You need to update PHP on the server.

Which PHP versions are patched?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older on those branches is affected, and PHP 8.1 or older only gets a fix if your host or Linux vendor provides one.

Will a WordPress security plugin protect me?

Not on its own. On mod_php servers the attack can happen before WordPress loads, so a plugin never sees it. Patch PHP first.

Can Web Brick Studio patch my server?

Yes. We check PHP versions, update self-managed servers, test sites on staging and move old sites to supported PHP safely. Get in touch and tell us where your site is hosted.

Keep reading

More from our blog.