On 21 October 2026 the PHP project published two critical vulnerabilities in PHP itself: CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS 9.2 (critical) and both can lead to remote code execution on the server without logging in. They are not WordPress or plugin bugs: every site running an unpatched PHP version is in scope, whatever CMS or plugins it uses.
The fix is simple: update PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or newer). Below is what the two flaws are, who is most at risk, how to check your version and how to patch on the most common setups.
The short version
| CVE-2026-109618 | CVE-2026-109619 | |
|---|---|---|
| Name | RCE via OOM corruption | RCE via stale global state |
| Type | Use after free (CWE-416) | Use after free (CWE-416) |
| Severity | CVSS 4.0: 9.2 critical | CVSS 4.0: 9.2 critical |
| Login needed | No | No |
| Affected | PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27, 8.5 before 8.5.12 | Same versions |
| Fixed in | 8.2.35 · 8.3.36 · 8.4.27 · 8.5.12 | 8.2.35 · 8.3.36 · 8.4.27 · 8.5.12 |
| Advisory | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
At publication, CISA’s assessment listed no known exploitation in the wild. That usually changes quickly once technical details are public, and both advisories describe the attack paths in detail, so treat this as urgent.
Still on PHP 8.1 or older? Those versions are past end of life and are not listed in the advisories because they no longer receive security fixes. Assume they are vulnerable and plan an upgrade to a supported branch now.
What the two flaws are, in plain words
CVE-2026-109618: out-of-memory corruption
When a PHP request runs out of memory, PHP jumps out of whatever it was doing to abort the request. In some places that jump leaves request memory half-initialised, and the cleanup that runs afterwards then reads it. The advisory shows several ways an attacker can deliberately push a request into “out of memory” while staying inside normal limits, for example with crafted multipart form uploads (many headers per part, empty file fields, deeply nested field names).
The PHP team confirmed full remote code execution against Apache with mod_php, where the attack works before any of your application code runs. PHP-FPM is considered susceptible, FrankenPHP is likely affected, and LiteSpeed (LSAPI) is expected to be exploitable in application-specific ways.
CVE-2026-109619: stale state between requests
A PHP worker handles many requests one after another. Some internal state (error, session, object and extension state) can survive from one request to the next while pointing at memory that has already been freed. A later request can then use that stale pointer before it is reset, and with a carefully prepared memory layout that becomes code execution. The demonstrated attack uses two HTTP requests that land on the same worker.
Step 1: check your PHP version
Any of these works:
- WordPress: Tools › Site Health › Info › Server › “PHP version”.
- Command line: run
php -v. Note that the command-line PHP can differ from the one serving your website. - Response headers: many servers send an
X-Powered-By: PHP/8.x.yheader you can see in your browser’s developer tools. - Hosting panel: cPanel “MultiPHP Manager”, Plesk “PHP Settings” or your host’s dashboard.
If the version is lower than the fixed release for its branch (for example 8.2.34, 8.3.35 or 8.4.26), you need to update.
Step 2: patch
Shared or managed hosting
Most hosts roll out new PHP point releases within days. Check your hosting panel for the new version and switch to it, or ask support directly: “Is PHP 8.x.y with the fixes for CVE-2026-109618 and CVE-2026-109619 available on my plan, and when?” Staying on the same branch (for example 8.3 to 8.3.36) is a low-risk update for WordPress.
Ubuntu or Debian with the ondrej/php packages
sudo apt update
sudo apt install --only-upgrade 'php8.3*' # use your branch: php8.2, php8.4, php8.5
php -v
sudo systemctl restart php8.3-fpm # and/or: sudo systemctl restart apache2If you use your distribution’s own PHP packages instead, check its security tracker: distributions often backport the fix without changing to the upstream version number.
cPanel / WHM
Update the EasyApache PHP packages (the ea-php packages) through WHM or your normal system updates, then confirm the new version in MultiPHP Manager.
Docker
Rebuild on the patched official image tag, for example php:8.3.36-fpm, then redeploy. A floating tag like php:8.3-fpm only picks up the fix when you pull and rebuild.
Then restart every PHP worker
Restart PHP-FPM, Apache (for mod_php) or LiteSpeed so that no old worker keeps running the vulnerable binary, then check the version again.
Step 3: if you cannot update today
The PHP team is clear that updating is the only complete fix. If you need a few days, these settings from the advisories reduce the risk:
- Set
session.upload_progress.enabled=0and restart PHP. This blocks the demonstrated session-based path of CVE-2026-109619, and few sites use the feature anyway. - On PHP 8.5, set
fatal_error_backtraces=0and restart PHP. This removes the trigger used in the confirmed CVE-2026-109619 attack. - Keep
post_max_sizeconservative, limit request body size at your web server or CDN, and lowermax_input_nesting_levelandmax_input_vars. If your site does not accept file uploads or multipart forms, block multipart requests in front of PHP. - Avoid fatal errors and PHP warnings on pages attackers can reach, and move per-directory PHP settings into
php.inior the FPM pool configuration so they are applied at startup.
The advisory also mentions memory_limit=-1 as the main configuration workaround for CVE-2026-109618, with clear caveats: it is not a complete fix, and removing the memory limit lets one request use all the server’s memory. On shared hosting you usually cannot set it, and you should not do it without a server-level memory limit in place. Ask your host or a developer first.
After patching
- Confirm the new version in Site Health or with
php -von the same PHP that serves the site. - Check the PHP error log for warnings or fatal errors you have been ignoring. Both CVEs feed on them.
- If the site ran an affected version and you see unknown admin users, unexpected files or strange outgoing traffic, follow our hacked site recovery checklist.
Want us to patch it for you? We update PHP on staging first, test your site, then patch production and confirm the version. Security work starts from €250, or it is included in our €69/month care plan. Get in touch.
Frequently asked questions
Do these PHP vulnerabilities affect WordPress sites?
Yes. They are in PHP itself, so any WordPress site running PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 or 8.5 before 8.5.12 is affected, regardless of theme or plugins.
Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?
PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, released on 21 October 2026, or any newer version.
Is PHP 8.1 affected?
PHP 8.1 and older no longer receive security fixes and are not listed in the advisories. Treat them as vulnerable and upgrade to a supported branch.
Are these vulnerabilities being exploited?
At publication on 21 October 2026, CISA listed no known exploitation. Detailed technical write-ups are public, so patch quickly rather than waiting.
Is there a workaround if I cannot update?
Only partial ones. Disabling session.upload_progress, setting fatal_error_backtraces=0 on PHP 8.5 and limiting multipart request size reduce the risk. The PHP team says updating is the only complete fix.