[Urgent] PHP CVE-2026-109618 and CVE-2026-109619: Update to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 Now (Two Flaws at CVSS v4.0 9.2) — Unauthenticated Remote Code Execution

PHP has fixed two critical vulnerabilities that can allow unauthenticated remote code execution (RCE). They are CVE-2026-109618 and CVE-2026-109619, and both are CVSS v4.0 9.2. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the PHP team says "all PHP users are strongly encouraged to update immediately". This follows our earlier advance-notice article.

Everything that serves web requests with PHP is at risk (PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, per the PHP team). It rates mod_php at the highest risk and says there is "a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs".

Check your PHP version first, then update to a fixed one. If you cannot update yourself (hosting or a managed service), check your provider's status.

Where this score comes from. 9.2 is the CVSS v4.0 value assigned by the CNA, the PHP Group, with the same vector for both: `CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N` (network, no authentication, no user interaction, high impact on confidentiality, integrity and availability, but rated as hard to exploit and needing preconditions). I checked it in the CVE Program's CVE records and in GitHub's advisories. NVD (NIST) did not yet have a record for either CVE as of 14:09 UTC on 21 October 2026 (23:09 in Japan; right after publication, so probably not yet ingested; there is no NVD score of its own). GitHub's advisories list weaknesses such as use after free (CWE-416).

What to do now

• ✓★Find out your PHP version. Run `php -v` on the command line. The PHP your web server uses can be a different version, so also check the control panel or phpinfo() (our note)
• ✓Update to a fixed version. 8.5.12 for the 8.5 branch, 8.4.27 for 8.4, 8.3.36 for 8.3 and 8.2.35 for 8.2. Source and Windows builds are on php.net's download page (PHP team)
• ✓On Linux, check your OS or distribution packages first. The PHP team says "Linux distributions and LTS vendors received the patches in advance", so look for the vendor's updated packages
• ✓If you use Remi's repository (rpms.remirepo.net), take care. The PHP team says it is volunteer-maintained and "will not have updates today", and urges switching to distribution packages or building from source
• ✓After updating, restart every PHP worker. This replaces old processes with the new version (our note; the team's mitigation notes require restarting all workers after config changes)
• ✓If you use containers, confirm for yourself that the image has been replaced with a fixed version. The announcement says nothing about container images (our note)
• ✓If you use hosting or a managed service, read your provider's notice. If you cannot update yourself, you will be waiting for the provider (our note)
• ✓PHP 8.1 and older no longer get updates from the PHP project. The team tells you to use a backport from your distribution or LTS vendor, or move to a supported version. For people who build from source, it published minimal source backports for PHP 7.4, 8.0 and 8.1 as GitHub branches (see "Pages we relied on")

If you cannot update right away: partial mitigations (not complete)

The PHP team says "only an update is a complete solution"; the measures below reduce exposure to specific attack paths but do not make an installation safe. They are listed as stopgaps, following the team's wording.

• ▸CVE-2026-109618 (OOM): set `memory_limit=-1`, in a way applications cannot override (a `php_admin_value` in the FPM pool, or the Apache configuration), and check no other setting puts a finite limit back. This removes the controllable PHP memory-limit failure, but an underlying allocation failure can still reach the vulnerable path
• ▸Set a low `post_max_size`: the php.net announcement says 8M if you do not need file uploads and 32M if you do, with `upload_max_filesize` kept below `post_max_size` (the specific numbers are in the announcement; the GitHub advisory only says to keep it conservative). Also enforce limits at the web server or proxy on decoded request size, input field count, multipart part count, header count and nesting depth, including for requests without a usable Content-Length
• ▸A container or cgroup memory limit can serve as an availability boundary, but do not use `RLIMIT_AS` or `RLIMIT_DATA`, because they can cause the vulnerable allocation failure
• ▸CVE-2026-109619 (stale state): set `session.upload_progress.enabled=0` and restart every worker. Use `php.ini`, an FPM pool or server configuration that applies before request parsing; do not rely on `ini_set()` or `.user.ini`. It blocks the confirmed paths but not other variants
• ▸On PHP 8.5, set `fatal_error_backtraces=0` and restart every worker. This blocks only the confirmed fatal-backtrace path
• ▸Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with `error_reporting`, `display_errors` or `@` does not help
• ▸Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing, and cleanup

What the two flaws are (from the official advisories)

• ▸CVE-2026-109618, "RCE via OOM corruption": PHP uses `longjmp()` to leave a request on out-of-memory (OOM). If that happens before request memory is fully initialized, PHP does not account for the early exit and leaves the memory in an invalid state, which request shutdown then reads, leading to remote code execution. The advisory lists multipart-parsing problems, such as requests without a usable declared length and parts with unlimited headers, that can exhaust memory
• ▸CVE-2026-109619, "RCE via stale global state": state kept by a worker (error, session, object, extension state) can keep pointing at request memory that has been freed, and a later request handled by the same worker uses it before initialization, causing a use after free. The two confirmed consumers are warnings about INI settings before initialization and session upload progress
• ▸Read the two together: each advisory tells you to follow the other's remediation advice too
• ▸Confirmed impact: unauthenticated remote code execution with the web worker's privileges. Full RCE over HTTP was validated against mod_php with default input and memory limits and normal prefork configurations. For CVE-2026-109619 the PHP 8.5 fatal-error backtrace path and the session upload progress path were confirmed, and the latter was also validated on FPM (a normal dynamic pool, depending on the application)
• ▸On FPM: it exits the child when startup fails, which blocks some CVE-2026-109618 paths, but later paths remain possible; the advisory says no complete FPM exploit has been demonstrated for that one. FrankenPHP is analyzed as likely behaving like mod_php, and LSAPI like FPM

Affected and fixed versions (from the PHP team)

• ▸PHP 8.2: earlier than 8.2.35 is affected → 8.2.35
• ▸PHP 8.3: earlier than 8.3.36 is affected → 8.3.36
• ▸PHP 8.4: earlier than 8.4.27 is affected → 8.4.27
• ▸PHP 8.5: earlier than 8.5.12 is affected → 8.5.12
• ▸PHP 8.1 and older: not in the official affected-version list. But because the team published minimal backports for 7.4, 8.0 and 8.1, it is reasonable to assume they have the same problem (our inference)

Timeline

• ▸20 October, 20:32 UTC: the PHP security team gave advance notice of a release at 14:00 UTC on 21 October (23:00 JST), with two flaws at CVSS v4.0 9.2
• ▸21 October, 13:34 UTC (22:34 JST): the two GitHub advisories were published
• ▸21 October, 13:48 / 13:54 UTC: the CVE Program records for CVE-2026-109618 / CVE-2026-109619 were published (state PUBLISHED)
• ▸21 October, 14:07 UTC (23:07 JST): I confirmed the four fixed versions and the security announcement on php.net

What I could not confirm

• ▸Whether the flaws are being exploited in the wild. The team says a working exploit was demonstrated, but does not say attacks are already happening. They were not in the copy of CISA's KEV (its catalog of known exploited vulnerabilities) I retrieved, updated 20 October 2026 at 19:00 UTC
• ▸Indicators of compromise and how to detect an attack. The team does not say how to tell whether you were hit. The log review (repeated fatal errors, warnings, execution timeouts) is offered as a way to reduce exposure, and the team itself says that no sign in the logs is not proof of safety
• ▸The NVD record and score. NVD had no record as of 14:09 UTC on 21 October 2026. It will probably appear within hours to days, which I have not checked
• ▸An official table for 8.1 and older. Only 8.2 to 8.5 are in it
• ▸What distributions, container images and hosts have done. The team only says to ask your vendor; I did not check individual vendors
• ▸The release date as written. php.net's front-page news says 21 October, while the ChangeLog entries for 8.5.12 and the others say 22 October; they do not match
• ▸The full technical detail. This article covers the key points. The attack conditions and configuration details are in the two GitHub advisories

Three lines to share

• ▸PHP has two critical flaws that can allow unauthenticated remote code execution (CVE-2026-109618 and CVE-2026-109619, both CVSS v4.0 9.2). The PHP team says Apache mod_php is at particular risk
• ▸★Update now to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35. Check your OS packages and your host's response, and restart workers after updating. For 8.1 and older, use a vendor backport or move to a supported version
• ▸Mitigations if you cannot update are only partial: `memory_limit=-1` (not overridable), a low `post_max_size`, `session.upload_progress.enabled=0`, and on PHP 8.5 `fatal_error_backtraces=0`. None is complete