Article · Oct 21, 2026 · 6 min read

Critical PHP flaws: update PHP on your WordPress site now

Two critical PHP flaws disclosed on 21 October 2026 (CVE-2026-109618 and CVE-2026-109619) let an attacker run code on a server without logging in. Update to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12. Here is how to check, how to update, and what to do if you can't yet.

Critical PHP flaws: update PHP on your WordPress site now

On 21 October 2026 the PHP team published two critical security advisories, CVE-2026-109618 and CVE-2026-109619. Both let an attacker run their own code on a web server without logging in. On a WordPress site that means they can copy the database, add themselves as an administrator or plant malware.

The flaws are in PHP itself, so it does not matter which theme or plugins you use. If your site runs on PHP and you have not updated today, it is exposed.

A large share of the sites that use Prosopo run WordPress, so we have emailed those customers directly. This page is the longer version of that email.

Update to one of these versions

PHP branchFixed inStatus
8.58.5.12Supported
8.48.4.27Supported
8.38.3.36Security fixes only
8.28.2.35Security fixes only
8.1 and olderNo fixOut of support. Move to 8.2 or later

Both advisories say the same thing: updating PHP is the only complete fix. The settings changes further down reduce the risk but do not remove it.

How to check which PHP version you are on

In WordPress: go to Tools → Site Health → Info, then open Server. The PHP version is listed there.

On your own server: php -v shows the command-line version. The web server can use a different one, so the safest check is a temporary phpinfo() page, which you should delete as soon as you have read it.

If your Linux distribution supplies PHP: Debian, Ubuntu, Red Hat and others often patch their own packages without changing the main version number. Look for CVE-2026-109618 and CVE-2026-109619 in your distribution's security notices instead of relying on the number.

How to update

Shared hosting or a cPanel/Plesk host. Most control panels have a PHP version setting, usually called "PHP version", "Select PHP Version" or "MultiPHP Manager". Your host still has to have installed the patched release, so if the latest version shown is older than the table above, ask their support when it will be available.

Managed WordPress hosting. Your host controls PHP. Ask support directly whether they have rolled out 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or patched packages for your version.

Your own server or VPS. Install your distribution's security updates, or update the official PHP packages or Docker images. Then restart every PHP process, meaning PHP-FPM, Apache (for mod_php) or FrankenPHP. A patch on disk does nothing until the running workers are replaced.

If you are on PHP 7.x or 8.1. These will not be fixed. Moving to 8.2 or later can break old plugins or themes, so take a backup, update your plugins first, and try the new version on a staging copy if your host offers one. Running an unsupported PHP version was already risky. As of today it is an open door.

If you cannot update today

These come from the advisories. Each one closes one known route of attack. None of them makes you safe. Make the change in your main PHP configuration (php.ini or the PHP-FPM pool), not per directory, and restart PHP afterwards.

  • Set session.upload_progress.enabled=0. This blocks the session-based attack that was shown to work against both Apache and PHP-FPM. WordPress does not need this feature, so you can leave it off after you update.
  • On PHP 8.5, set fatal_error_backtraces=0. This removes the other attack that was shown to work.
  • Block requests you don't need. If your site has no file uploads or multipart forms open to the public, block multipart/form-data requests at your firewall or reverse proxy before they reach PHP. Keep post_max_size low and limit request body size at the front end too.
  • Do not set RLIMIT_AS or RLIMIT_DATA. The advisory warns that these make one of the flaws easier to trigger, not harder.

The first advisory also suggests memory_limit=-1. That turns off PHP's memory cap altogether, which can let a single request use up all the server's memory, and the advisory itself says it is not a complete fix. Only consider it if you run your own server and understand the trade-off.

After you update: check you were not already hit

The advisories describe working attacks, and the details are public, so attacks on unpatched sites will follow quickly. Once you have updated, it is worth ten minutes to check:

  • Users. Look at Users → All Users in WordPress for administrators you don't recognise.
  • Files. Look for PHP files that should not be there, especially inside wp-content/uploads, which should only hold images and documents. A security plugin's file integrity scan can compare WordPress core files against the originals.
  • Plugins and settings. Check for plugins you did not install, and for changes to the site URL.
  • Secrets. If anything looks wrong, change the database password, regenerate the WordPress keys and salts in wp-config.php, reset administrator passwords and revoke any API keys stored on the site. Then restore from a clean backup if you have one.

What the two flaws are, in plain terms

CVE-2026-109618 (out of memory). When PHP runs out of memory part-way through a request, it can bail out while some of its internal memory is only half set up. The clean-up step that runs afterwards then trusts that memory. An attacker can deliberately push PHP to run out of memory while it is still reading a crafted upload request, which happens before WordPress or any plugin runs. The advisory confirms full code execution against Apache with mod_php on default settings. PHP-FPM and FrankenPHP are also believed to be vulnerable.

CVE-2026-109619 (stale state between requests). A PHP worker handles many requests one after another. Some leftovers from one request can survive into the next one after their memory has been freed. An attacker sends one request to leave the leftover behind and a second to make PHP use it, and from there can take over the worker. This was confirmed against both Apache with mod_php and PHP-FPM.

You do not need to understand either to fix them. Update PHP and restart it.

Why a captcha company is writing about PHP

Prosopo protects forms and sign-ups from bots, and a lot of our customers use us on WordPress through MC4WP or our Procaptcha plugin. A captcha stops automated form spam. It cannot stop an attacker who gets in through the server underneath the site. We knew which of our customers were likely exposed, so telling them was the right thing to do.

Prosopo's own service is not affected, and nothing in your Prosopo setup needs to change. If you have questions about any of this, get in touch.

Frequently Asked Questions

Which PHP versions are fixed?

PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, released on 21 October 2026. Anything older in those branches is vulnerable. PHP 8.1 and older are out of support and will not get a fix, so sites on them need to move to PHP 8.2 or later.

Is WordPress affected?

Yes. The flaws are in PHP itself, not in WordPress, a theme or a plugin. Every WordPress site runs on PHP, so every WordPress site on an unpatched PHP version is exposed. The same goes for Drupal, Joomla, Magento, Laravel and any other PHP application.

Do I need to be logged in or have a vulnerable plugin for this to work?

No. Both advisories describe unauthenticated remote code execution. One of them, CVE-2026-109618, is triggered while PHP is still reading the incoming request, before WordPress or any plugin code runs.

How do I check my PHP version in WordPress?

In the WordPress dashboard go to Tools, then Site Health, then the Info tab, and open the Server section. The PHP version is listed there. On a server you control you can also run php -v, but check the version your web server uses, which is not always the same as the command-line one.

My Linux distribution shows an older PHP version number. Am I still vulnerable?

Maybe not. Debian, Ubuntu, Red Hat and others often fix security flaws in their own packages without changing the main version number. Check your distribution's security notices for CVE-2026-109618 and CVE-2026-109619 rather than going by the version number alone.

Is Prosopo affected?

No. This is a flaw in PHP on the server that runs your website. Prosopo, MC4WP and the Procaptcha plugin do not need any changes, but the PHP they run on does.

Ready to ditch Google reCAPTCHA?

Start for free today. No credit card required.