PHP 8.2-8.5 – Critical Unauthenticated RCE (CVE-2026-109618, CVE-2026-109619)

Two critical PHP vulnerabilities can expose fully updated WordPress sites to unauthenticated remote code execution. CVE-2026-109618 and CVE-2026-109619 each carry a CVSS v4.0 score of 9.2 (Critical). The flaws are in the PHP interpreter beneath WordPress, so WordPress core, plugin, and theme updates do not install the fixes.

PHP has released patched versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Administrators must update the PHP service that handles web traffic and restart its workers. Security providers reported active probing and exploitation reports after technical details leaked, while some public telemetry initially showed probing without confirmed breaches. Treat every unpatched PHP web service as urgent.

Affected and Fixed Versions

• PHP 8.5: update to 8.5.12 or later.
• PHP 8.4: update to 8.4.27 or later.
• PHP 8.3: update to 8.3.36 or later.
• PHP 8.2: update to 8.2.35 or later.
• PHP 8.1 and older: these branches no longer receive upstream PHP releases. Obtain a vendor-confirmed backport for both CVEs or migrate to a supported branch.

Linux distributions and long-term-support vendors may backport the fixes without changing the main PHP version number. Verify the complete package revision and the vendor security advisory rather than relying on the version banner alone.

Attack Class and Impact

• CVE-2026-109618: an out-of-memory error can leave internal request data partially initialized. Cleanup may then treat invalid data as valid, enabling memory corruption and code execution.
• CVE-2026-109619: request-owned state can survive after its memory is released. A later request handled by the same worker may use stale state before normal initialization resets it.

No WordPress account is required. Successful exploitation runs with the PHP worker’s permissions and may expose wp-config.php, database credentials, API tokens, site files, customer data, and other secrets available to the web application. An attacker may alter WordPress files or establish persistent access.

PHP-FPM, Apache mod_php, CGI, FrankenPHP, and LiteSpeed environments can be affected. PHP considers the risk particularly serious for mod_php, where an attack path can run before WordPress starts. Application-only WAF rules therefore cannot replace the PHP update.

Immediate Remediation

1. Identify the PHP service actually serving each WordPress site, including staging sites, containers, alternate origins, and administrative tools.
2. Install PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35, or a vendor package explicitly confirmed to patch both CVE-2026-109618 and CVE-2026-109619.
3. Restart PHP-FPM, Apache, LiteSpeed, containers, or the relevant web service so no old worker remains in memory.
4. Verify the web-facing PHP runtime after restart. In WordPress, check Tools > Site Health > Info > Server.
5. Retain web-server, PHP, firewall, and system logs covering at least 48 hours before the October 21 release through the completed update and restart.
6. If patching was delayed or suspicious behavior appears, investigate the host, rotate credentials stored on it, and rebuild from known-clean images when integrity cannot be established.

Verification Commands

On a self-managed server, these read-only commands help identify installed PHP packages and active services. Package commands vary by operating system:

php -v
php-fpm -v
systemctl status php-fpm
systemctl status apache2
systemctl status httpd
dpkg -l | grep -E '^ii  php'
rpm -qa | grep '^php'

The command-line PHP binary may differ from the runtime serving WordPress. Confirm the version in WordPress Site Health and verify the package revision with the hosting provider, distribution, control panel, or container image vendor.

Indicators for Investigation

• Unusual multipart requests followed by memory-limit errors or bursts of HTTP 500 responses.
• Unexpectedly large or malformed PHPSESSID cookies in responses.
• Unexplained PHP worker crashes or restarts.
• New or modified PHP files, unfamiliar administrator accounts, altered scheduled tasks, or unexpected outbound connections after PHP failures.

These signals are not proof of exploitation, and their absence does not prove a server is clean. The vulnerabilities operate below the WordPress application layer, so WordPress logs may contain little useful evidence.

Temporary Mitigation

Only the PHP update fully fixes the vulnerabilities. If an update cannot be applied immediately, PHP’s advisory lists limited configuration changes for specific attack paths, including disabling session upload progress and constraining request sizes. These controls can disrupt uploads or application behavior and do not cover every variant. Apply them only at the server or PHP pool level after testing, then restart all workers. High-risk sites that cannot be patched should be placed behind strict access controls or taken into maintenance until the update is complete.

Do not install unofficial WordPress “fix” plugins or paste unverified snippets. WordPress code cannot reliably repair a memory-safety flaw in the PHP process, including paths that execute before WordPress loads.

Sources

• PHP security release announcement
• PHP advisory for CVE-2026-109618
• PHP advisory for CVE-2026-109619
• WordPress.org Critical PHP Security Release
• Wordfence testing and WordPress impact analysis
• Patchstack PHP security alert and timeline

Featured image source: Wordfence disclosure.