PHP 8.5.12 fixes two critical RCE vulnerabilities: what developers need to know

PHP released emergency security updates on 21 October 2026 for two vulnerabilities that can allow unauthenticated remote code execution. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you operate a PHP website or API, schedule the runtime update immediately. PHP's announcement covers PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, and identifies mod_php as the highest-risk configuration. Official security announcement

For application teams, the immediate task is to identify every runtime serving traffic, obtain its patched build, and verify that the running workers have actually changed. Today's release also includes fixes worth testing in applications that use PDO, Unicode processing and OPcache.

Which PHP versions need updating?

For installations using upstream PHP releases, use this table:

Both advisories list these patched versions. Each vulnerability has a CVSS v4.0 score of 9.2. OOM advisory, stale-state advisory

PHP 8.1 and older are outside upstream support. PHP has exceptionally provided minimal source backports for 7.4, 8.0 and 8.1, while distribution and LTS vendors may supply their own patched packages. Ask your vendor for the package revision addressing both CVEs. An older version string alone cannot establish whether a vendor backport is installed. PHP's upgrade guidance

CVE-2026-109618: memory exhaustion can corrupt request cleanup

PHP's handling of an out-of-memory error can interrupt work while internal request data is only partly initialized. Cleanup then encounters that invalid state. The advisory confirms remote code execution on Apache mod_php before application code starts, under normal prefork configurations and default PHP input and memory limits.

This makes framework middleware an insufficient boundary: Laravel or Symfony may never get the opportunity to reject the request. FPM handles failed request startup differently, but the advisory still considers it susceptible through later execution paths. A complete FPM exploit for this particular CVE had not been demonstrated in the published report. CVE-2026-109618 details

CVE-2026-109619: a worker can retain freed request state

The second flaw involves state that survives after the memory belonging to a request has been released. Another request reaching the same worker can cause PHP to use that stale state before ordinary initialization replaces it.

Exploitation requires both an operation that leaves the state behind and a later operation that consumes it. The published advisory confirms remote code execution through session lifecycle handling on both mod_php and FPM. The FPM case depends on a suitable application operation. PHP 8.5's fatal-error backtrace handling provides another confirmed mod_php path.

Successful exploitation runs with the web worker's privileges. More workers can reduce an attack's success per attempt, but do not remove the flaw. CVE-2026-109619 details

Configuration changes cannot replace the patch

PHP explicitly says there is no complete configuration mitigation. Its temporary guidance includes disabling session upload progress before request parsing and restarting workers; PHP 8.5 also has guidance for disabling fatal-error backtraces. These measures address specific paths only. PHP's temporary mitigation guidance

The OOM advisory also discusses enforcing memory_limit=-1. That removes a predictable PHP limit failure, but underlying allocation failures remain possible. Removing a memory limit affects availability planning, so follow the advisory's full resource-control guidance rather than applying that setting in isolation. OOM mitigation details

What else changed in PHP 8.5.12?

The PHP 8.5.12 changelog contains a substantial set of additional repairs. These are changes in this patch release:

• PDO: failed statement execution no longer leaves the previous result available. Another fix prevents destroying one persistent PDO instance from rolling back a transaction another instance still uses.
• BCMath: BcMath\Number results truncated to zero no longer retain a negative sign and compare below zero.
• Intl and MBString: fixes cover grapheme searches, byte offsets in date parsing, truncated UTF-8 input and invalid surrogate output.
• OPcache and JIT: fixes address incorrect lazy-proxy property reads, property writes involving inheritance, and several optimizer crashes or incorrect results.
• DOM: HTML document lookup now finds IDs on SVG and MathML elements; XPath fixes preserve context during nested callback evaluations.
• Streams and hashing: TLS handshake timeouts no longer leave affected sockets nonblocking, and sha1_file() no longer returns a digest for incomplete data following a stream read failure.

These examples come from the PHP 8.5.12 changelog. Check your own branch's entry before assuming the same collection applies to PHP 8.4, 8.3 or 8.2.

A practical deployment and verification sequence

Start with an inventory. Include every application pool, container image, staging host reachable from the internet, and separate service running embedded PHP. Give each item an owner and record the package or image revision selected for deployment.

On machines with a PHP CLI, these commands identify its version, configuration files and loaded modules:

php -v
php --ini
php -m

The PHP CLI documentation describes these options. The shell's PHP binary may differ from the runtime serving HTTP. Verify the web service separately through your hosting controls or private operational tooling. Avoid publishing a diagnostic endpoint just to check a version.

For Composer applications, run this inside the updated deployment environment:

composer check-platform-reqs --no-dev

Composer checks the actual PHP and extension requirements of installed production dependencies, ignoring any simulated config.platform values. Passing this check establishes compatibility with those requirements; it does not certify that a security patch is installed. Composer documentation

For containers, update the base image reference or pinned digest to a verified patched build, rebuild, then replace running containers. Docker's --pull build option checks for a newer base image; --no-cache alone does not. A successful build still needs deployment to every replica. Docker build guidance

Keep the change focused enough to review quickly. Record the previous runtime, the replacement build, required extensions and any configuration differences. Use the same deployment artifact in staging and production so the checks apply to what you release. If a hosting provider manages PHP for you, ask for confirmation of the installed package revision and completion of worker replacement across your account.

Choose regression checks around the code your application actually executes. A service using persistent database connections should exercise transaction boundaries. A document importer should process representative Unicode and HTML inputs. Preserve the results in the deployment record so another developer can verify what was checked.

Finally, exercise login, uploads, database transactions and the application's main request paths on the patched runtime. Restart or replace the relevant PHP workers using your platform's deployment procedure. Check every replica, watch error rates, and record the deployed runtime revision alongside the verification result. Close the upgrade task only when the serving processes are confirmed patched.