PHP runtime affected by CVE-2026-109618

PHP runtime affected by CVE-2026-109618 / CVE-2026-109619: What It Means and How to Fix It

The PHP version disclosed by this WordPress server is affected by CVE-2026-109618 and CVE-2026-109619, two critical runtime flaws that can lead to unauthenticated remote code execution.

Do this: Update PHP to the fixed release and restart every worker. These runtime flaws can give an unauthenticated attacker control of the PHP process. Open the page you need

PassThe disclosed PHP version is at or above the fixed release; a hidden version is not treated as a pass.

CriticalThe disclosed PHP runtime is in the affected range for both critical CVEs.

The fix, in one snippet

Example to adapt Verify, update, restart

php -v
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.2-fpm

Illustrative values. Change the paths, hostnames and options to match your own site before using it.

The sections below explain what is tested, why it matters and the alternatives.

What we test

Scan.now reads the ordinary homepage response headers and looks for a complete PHP version in X-Powered-By or Server. It does not send an exploit, an out-of-memory request or a multipart upload. PHP 5.4 through 8.1 are affected and have no upstream fix on those branches. On supported branches, versions before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 fail this check. A version at or above the fixing release passes. If the server does not disclose PHP, the result is skipped and explicitly says the runtime could not be verified; removing X-Powered-By does not earn a pass. This is deliberately a version check because safely reproducing cross-request memory corruption is not an appropriate external scan. Distribution backports are a known limit: a vendor can patch an older-looking package without changing the upstream version string, so its package tracker takes precedence over the header.

Why it matters

CVE-2026-109618 and CVE-2026-109619 are flaws in PHP's fatal-error handling. Request-owned pointers can survive after their memory is freed, and a later request handled by the same worker can use that stale state before normal initialisation replaces it. Published research demonstrates paths from that condition to memory disclosure and attacker-controlled code execution without an account or user interaction. Both vulnerabilities have a 9.2 Critical CVSS 4.0 score; NVD also gives CVE-2026-109619 a 9.8 CVSS 3.1 score. The flaw is below WordPress, so updating WordPress core, plugins or themes does not patch it. A vulnerable PHP runtime can expose any PHP application it serves, and the worker processes must be replaced after the package or image is updated. See the full response guide for the exploit conditions and temporary mitigations.

How to fix it

Update to the fixed release on the installed branch, then restart every PHP worker. PHP 8.1 and older must move to a supported branch:

# Verify the CLI runtime
php -v

# Debian or Ubuntu example
sudo apt update
sudo apt upgrade
sudo systemctl restart php8.2-fpm

# Rebuild containers; do not only restart the old image
docker build --pull --no-cache -t my-wordpress:patched .
docker compose up -d --force-recreate

Confirm the web-serving runtime separately from command-line PHP, because FPM and the CLI can use different packages. On managed hosting, ask for the full patch version rather than “PHP 8.2”. If the host backported the fix, obtain its CVE notice or package changelog. The PHP project's configuration mitigations are partial and should only bridge the time needed to deploy the patched runtime.

Where this fits

PHP runtime affected by CVE-2026-109618 / CVE-2026-109619 is check 1 of 11 that the website vulnerability scanner runs under wordpress plugins, themes and core, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.

What fixing this still leaves open

PHP runtime affected by CVE-2026-109618 / CVE-2026-109619 closes one route in. Immediately below it: WordPress install or upgrade script reachable, where the WordPress installer or database upgrader answers with its setup page instead of 'already installed'; Exposed wp-content/debug.log, where the WordPress debug log at /wp-content/debug.log is readable by anyone; Plugin version with known vulnerabilities, where at least one installed plugin is at a version with published vulnerabilities.

Found in the same scan

The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and Exposed .env configuration file, where a .env configuration file is served from the web root. A single run of website vulnerability scanner answers all of them at once.

Prompt for an AI Hand this check to an assistant Sign in to copy it

The first few lines

You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.

Finding: PHP runtime affected by CVE-2026-109618 / CVE-2026-109619 (critical severity)
Scanner check id: wordpress-vulnerable-php-runtime

19 more lines, including the evidence and the exact fix

The rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.

Signing in is free and takes one click. We store your email address and nothing else.