Critical PHP Remote Code Execution Flaws: How to Patch Your Servers

On October 21, 2026 the PHP project published two critical security advisories together with fixed releases for every supported branch: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Each PHP RCE vulnerability, CVE-2026-109618 and CVE-2026-109619, can let an attacker run code on a server without logging in, and both are rated 9.2 (Critical) on CVSS v4. If you are responsible for a server that runs PHP, the PHP project's advice is to update now.

Below is what the two advisories say, which servers face the highest risk, how to confirm the PHP version your sites really use, and what you can change today if the update has to wait a day. Everything here comes from the advisories and php.net.

What the two PHP advisories describe

The first advisory, GHSA-w8hw-w9fx-j79w (CVE-2026-109618), is about how PHP reacts when a request runs out of memory. PHP aborts the request by jumping out of whatever code was running. In some places memory is reachable before it has been fully set up, so that early exit can leave it in an invalid state, and the request shutdown code then works with it. The PHP team confirmed unauthenticated remote code execution as the account the web server runs PHP under. Several weaknesses in how PHP parses multipart form requests (the format browsers use for file uploads) can push a request into that out-of-memory state while it still appears to be inside PHP's limits. Application code that makes large allocations from user input can do the same.

The second advisory, GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), affects servers where one PHP worker handles many requests in turn, which is how almost every production setup works. A fatal error such as an out-of-memory condition or a timeout can skip the cleanup between requests and leave global state pointing at memory that has been freed. A later request handled by the same worker can then act on it. The confirmed paths run through the session upload progress feature, and through fatal error backtraces on PHP 8.5.

The new releases change how PHP stops a request that runs out of memory, so it no longer leaves memory half set up. Both advisories say that updating is the only complete mitigation.

Affected PHP versions and the releases that fix them

Every version below the patched release in its branch is affected.

Branch	Affected	Update to
PHP 8.5	Below 8.5.12	8.5.12
PHP 8.4	Below 8.4.27	8.4.27
PHP 8.3	Below 8.3.36	8.3.36
PHP 8.2	Below 8.2.35	8.2.35

No fixed release exists for PHP 8.1 or anything older, because those branches no longer receive security fixes. A server on one of them needs a move to a supported branch, not a patch. The 8.2.35 release notes also say that PHP 8.2 reaches end of life on December 31, 2026, so a site leaving 8.1 now should aim for 8.3 or later if its code allows. php.net keeps the current dates on its supported versions page.

Which servers face the highest risk

How PHP is connected to the web server, known as the SAPI, changes how exposed a server is. The first advisory is specific about each one.

Setup	What the advisory reports
Apache with mod_php	Request shutdown runs even when request startup failed, so attacks that do not depend on your application work. Full remote code execution was validated over HTTP with default limits and prefork settings.
PHP-FPM (behind Nginx or Apache)	The worker exits when request startup fails, which closes the application-independent path. An out-of-memory error after normal startup can still reach the vulnerable code. No complete FPM exploit was demonstrated for this flaw, but the second advisory's session upload progress path gives code execution under FPM.
FrankenPHP	Source analysis indicates it behaves like mod_php.
LiteSpeed (LSAPI)	Modeled on FPM. Application-specific exploits are considered likely but were not validated.

Apache with mod_php in prefork mode is still common on self-managed VPS servers and older control panel setups, often with many sites sharing one server. If that describes yours, the update is today's job. FPM servers should not wait long either, since the second advisory confirms code execution there too.

Check which PHP version your sites really run

Running php -v over SSH shows the command-line version, which is often not the one serving web pages. A server can have several PHP versions installed with each site pointed at a different one, so check what the web server itself uses.

1. Create a temporary file containing <?php phpinfo();, open it in a browser and read the PHP version and the "Server API" line. "Apache 2.0 Handler" means mod_php, "FPM/FastCGI" means PHP-FPM and "LiteSpeed" means LSAPI. Delete the file as soon as you have read it.
2. On a server with several versions, list them all: ls /etc/php/ on Debian and Ubuntu, or the PHP version manager in cPanel or Plesk. Every installed version that serves a site needs the update.
3. In WordPress, Tools > Site Health > Info > Server shows the PHP version the site runs on.
4. For Docker, check the PHP tag in your Dockerfile. A container keeps the PHP it was built with until you rebuild it from an updated base image and redeploy.

One thing catches people out. Linux distributions such as Debian, Ubuntu and Red Hat often patch their own PHP packages without changing the upstream version number. A distribution package can be fixed while still reporting an older version, or the fix may not have reached it yet. Search your distribution's security tracker for the two CVE numbers instead of relying on the version string alone.

Update PHP and restart every PHP process

This is the order we follow on the servers we look after:

1. Take a snapshot of the server, or at least a backup of its sites and databases.
2. Install the fixed packages through your package manager (sudo apt update then sudo apt upgrade, or sudo dnf upgrade) or through your control panel's PHP manager.
3. Restart whatever runs PHP, because the old code stays in memory until you do: sudo systemctl restart apache2 for mod_php, or the FPM service for each version you updated, for example sudo systemctl restart php8.3-fpm.
4. Load your phpinfo file again, confirm the new version, then delete the file.
5. Open the main pages of each site, submit a form, log in to the admin area and keep an eye on the error log for the next hour.

A move within a branch, say from 8.3.30 to 8.3.36, carries little risk because patch releases contain bug and security fixes only. Leaving PHP 8.1 for a newer branch is a different job: deprecated functions turn into errors and old plugins break, so test on staging first. Our guide to upgrading the PHP version of a WordPress site covers that testing step by step.

On shared or managed hosting you usually cannot update PHP yourself. Ask your host directly whether the servers your account runs on have the fixed releases, or patched distribution packages, and when they will.

What to change today if you cannot update yet

Both advisories list interim steps. None of them is a complete fix, so treat them as cover until the update is done, and restart the PHP processes after each change.

• Turn off session upload progress with session.upload_progress.enabled = 0 in php.ini. Few sites use it, and the second advisory recommends leaving it off even after patching if you do not need it.
• On PHP 8.5, set fatal_error_backtraces = 0 to close the other confirmed path from the second advisory.
• Limit requests before PHP sees them. Set a request body limit in the web server (LimitRequestBody in Apache, client_max_body_size in Nginx), keep post_max_size conservative, and lower max_input_vars, max_input_nesting_level, max_multipart_body_parts and max_file_uploads to what your forms need. If an application never accepts uploads or multipart forms, block multipart requests to it at the web server or firewall.
• Consider memory_limit = -1, enforced by the administrator in php.ini or with php_admin_value in the FPM pool, so application code cannot change it. The first advisory names this as the main configuration mitigation, because the flaw sits in how PHP reacts to reaching its own memory limit, and it also says the measure is not complete. It removes PHP's own safety net, so pair it with the request limits above and a container or cgroup memory limit, which the advisory describes as helpful but not guaranteed.
• Do not add RLIMIT_AS or RLIMIT_DATA limits as a workaround. The advisory warns that they cause memory allocation to fail in a way that leads into the same vulnerable path.
• On PHP-FPM, consider pm.max_requests = 1 so no worker carries state from one request to the next. It costs real performance, which is why the second advisory suggests it only where performance allows.

Check your logs after you patch

The advisories do not publish a list of attack indicators, and the second one says plainly that logs alone cannot prove a server is safe. They are still worth a look. In the PHP error log, look for bursts of "Allowed memory size exhausted" and "Maximum execution time exceeded" fatal errors on pages that do not normally produce them. In the access log, look for unusual multipart POST requests from addresses you do not recognize. Then run the general checks you would after any suspected compromise: PHP files that changed outside a deployment, new admin accounts, unfamiliar cron jobs and unexpected outgoing connections from the server.

If something looks wrong, take a copy of the logs before you change anything else, then rotate the database passwords and API keys stored on that server.

When to handle it yourself and when to get help

A single server with one PHP version, a package manager you are comfortable with and a recent backup is a short job you can do yourself by following the steps above. Get help when the server runs mod_php for many sites, when several PHP versions are installed and nobody is sure which site uses which, when a site is still on PHP 8.1 or older, when your distribution has not shipped the fix yet, or when your logs show any of the signs in the previous section.

If you would like us to take it on, contact our team and tell us the PHP version and the "Server API" line from phpinfo for each server. We reply within one business day. We will check which servers and sites are affected, apply the update and restart PHP, test the sites afterwards, and plan the move for anything on an unsupported branch through our PHP migration and upgrade service. To keep future security releases from turning into emergencies, our PHP maintenance and support plans include version updates as routine work, and WordPress sites get the same under WordPress maintenance.

Frequently asked questions

Is my WordPress site affected?

It depends on the PHP version your server runs, not on WordPress. WordPress core, plugins and themes have nothing to update for these flaws, because the fix is in PHP itself. Check Tools > Site Health > Info > Server for the version, and ask your host if you cannot update PHP yourself.

Do I need to change my application code to apply the fix?

Not for an update within your current branch, such as 8.3.x to 8.3.36. Patch releases contain bug and security fixes only, so code that runs today should keep running. Code changes come in only when you move from an unsupported branch such as 8.1 to a newer one.

Will PHP 8.1 or 7.4 get a fix?

No. The advisories list every version below the patched releases as affected, and fixed releases were published only for PHP 8.2, 8.3, 8.4 and 8.5. A server on 8.1 or older needs to move to a supported branch, and the interim settings above are the only cover until it does.

Is a server running PHP-FPM safe to leave until later?

No. FPM is less exposed to the first flaw than mod_php, but the advisory still describes a path to the vulnerable code, and the second advisory confirms remote code execution under FPM through session upload progress. Plan the update for FPM servers in the same window.