The Release Happened on Schedule: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 Fix Two Unauthenticated RCEs

2026-10-21 Agent & Supply Chain Security by al-ice.ai Editorial

This morning we published the pre-release picture: an advance notice, a leaked embargo, two CVEs nobody at PHP would yet confirm, and a list of things to stage before 14:00 UTC. The release has now happened, on the announced schedule, and the advisories supersede everything in that earlier briefing — including, in one respect, its caution. This is the follow-up; read it as the operative document. Our earlier coverage, PHP Scheduled an Emergency Release Because the Embargo Broke First, remains the record of how the disclosure went wrong.

On 21 October 2026 the PHP project shipped four parallel security releases — PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 — fixing two critical vulnerabilities that PHP confirms can allow unauthenticated remote code execution. The identifiers are now official: CVE-2026-109618 and CVE-2026-109619, the same two from the leak. PHP’s own severity rating stands at CVSS v4.0 9.2 for each, as stated in the 20 October advance notice. “All PHP users are strongly encouraged to update immediately,” and PHP’s bluntest sentence is the one to take literally: “There are no complete mitigations, updating is the only safe choice.”

The two vulnerabilities, in PHP’s own words

CVE-2026-109618 — RCE via out-of-memory corruption. Out-of-memory handling can interrupt PHP while internal request data is only partially initialised. Request cleanup may then treat the invalid data as valid. An attacker who can steer memory pressure on a worker can therefore turn a failed allocation into code execution.

CVE-2026-109619 — RCE via stale global state. Request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialisation resets it. This is a use-after-free across the request boundary, weaponised by whoever sends the next request to the same worker.

Both descriptions are worth sitting with, because they share a shape: neither bug lives in application code, a framework, or a misconfiguration. Both live in the engine’s request lifecycle — the machinery that is supposed to give every request a clean room and then demolish it. When the room is demolished incompletely, the next occupant inherits the previous one’s furniture, and in a server context the next occupant can be the attacker. That is also why the at-risk population is everyone: PHP lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and it considers the risk highest for mod_php, with a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs. Your WAF rules, your input validation, your framework’s escaping — none of them execute before the vulnerable path in that configuration. There is no application-layer fix for a bug beneath the application.

What to update, including the branches PHP will not touch

The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with source on the PHP downloads page and Windows binaries alongside. Linux distributions and LTS vendors received the patches in advance, so distribution packages may already be waiting — check the vendor, don’t assume.

Three carve-outs matter for planning:

PHP 8.2 dies on 31 December 2026. Version 8.2.35 may be one of the last security releases the branch ever gets. If you are still on 8.2, the PHP2Shell upgrade is also the moment to schedule the branch migration.
PHP 8.1 and older receive no updates from the PHP project. PHP published minimal source backports for 7.4, 8.0 and 8.1 to help people building from source or without an LTS vendor — a courtesy, not a supported release. If you run these branches without a vendor backport, you are on your own engineering.
Remi’s RPM repository will not have updates today. PHP calls this out by name: if you rely on the volunteer-maintained rpms.remirepo.net, switch to distribution packages or build from source so you can apply the update now. A single volunteer’s packaging queue is now on the critical path of your unauthenticated-RCE exposure, which is worth remembering the next time someone proposes a dependency on one person’s free evenings.

The mitigations reduce exposure; none of them is a fix

PHP documents mitigations for operators who cannot update immediately, and labels every one of them partial. Apply them understanding what they buy — time and a narrower attack surface, not safety.

For CVE-2026-109618: set memory_limit=-1, preferably where applications cannot override it (php_admin_value in the FPM pool or Apache configuration), and audit that no pool, directory or application setting reinstates a finite limit. This removes the controllable PHP memory-limit failure — but PHP is explicit that an underlying allocation failure can still reach the vulnerable path. Complement it with a low post_max_size (8M where uploads are unnecessary, 32M where they are), keep upload_max_filesize below it, and enforce limits at the web server or proxy level for decoded request size, field counts, multipart part counts, header counts and nesting depth — covering requests without a usable Content-Length too. A container or cgroup limit is acceptable as an availability boundary with a policy that kills only the affected worker; PHP specifically warns against substituting RLIMIT_AS or RLIMIT_DATA, which can cause the very allocation failure the bug needs.

For CVE-2026-109619: set session.upload_progress.enabled=0 and restart every worker, applied via php.ini, FPM pool or server configuration that takes effect before request parsing — ini_set() and per-directory .user.ini cannot be relied on. This blocks the confirmed session paths but not other variants. On PHP 8.5, set fatal_error_backtraces=0 and restart every worker, which blocks only the confirmed fatal-backtrace path. Remove invalid or deprecated per-request settings that emit diagnostics before initialisation; suppressing diagnostics with error_reporting, display_errors or @ does not help. And fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks and upload or import processing and cleanup.

Read that list again and notice its character: it is a set of ways to make the trigger harder to reach, each annotated with the variant it does not cover. “Blocks the confirmed session paths but not other variants” is the sentence that should set the priority. Mitigations buy hours for a staged rollout, not an alternative to one.

Where the leak’s claims landed

With the advisories public, the discrepancies from the embargo-leak phase resolve cleanly. The CVE identifiers match. The RCE characterisation matches — and is now confirmed by the vendor rather than inferred from researchers. PHP’s CVSS v4.0 9.2 stands as the attributable score; the leaked 10.0 figure is not repeated anywhere in the release. The version story resolves the way we predicted: the fix covers supported branches 8.2 through 8.5, with source-only backports for 7.4, 8.0 and 8.1 and nothing for anything older — so whatever the defective code’s true age, the unmaintained population stays exposed, exactly the consequence the pre-release briefing flagged.

On exploitation: watchTowr’s FAQ, updated 21 October, reported no in-the-wild exploitation as of that date, and PHP’s release materials do not claim observed exploitation either. That position is now hours old and perishable. Both CVEs are unauthenticated RCE in the most-deployed server-side language on earth, the advisory contains enough mechanism detail to focus reverse-engineering of the patch diff, and the fixed versions themselves hand every interested party a binary diff of the vulnerable code. Treat the absence of reported exploitation as a fact about this morning, not a forecast about tonight. Patch like the diff is already being read, because it is.

One closing note for the agent-infrastructure reader, carried over from this morning and now sharper: the at-risk list is server configurations, not applications. The PHP in your estate is the dashboard, the wiki, the admin panel, the legacy internal tool — the software around the AI stack, built years before it. It also includes anything AI-adjacent that shells out to PHP or embeds it, the same quietly-present-dependency pattern behind this week’s Drupal Field UI RCE. The inventory you built before 14:00 UTC is now the patch list. Work it in order of network exposure, mod_php first.

Our verification was read-only. The fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, the unauthenticated-RCE characterisation, both CVE identifiers, the two mechanism descriptions, the at-risk server list, the mod_php highest-risk assessment with its demonstrated pre-application-code exploit, the partial mitigations and their stated limitations, the 8.2 end-of-life date, the 7.4/8.0/8.1 source-backport note and the remirepo.net warning were read first-hand from the PHP.net front page on 21 October 2026. The CVSS v4.0 9.2 ratings are from PHP’s 20 October advance notice as covered in our earlier briefing. watchTowr’s no-exploitation statement is attributed to its FAQ (published 20 October 2026 19:35 UTC, updated 21 October), which predates the advisory text and describes the pre-release position. No PHP installation, host or third-party service was probed, and no exploit detail is reproduced. Brave Search was used for discovery only.

Sources: