PHP Security Release October 2026: Two Critical RCEs

PHP shipped an emergency security release on 21 October 2026 that closes two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Every PHP installation serving web requests is in scope — PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. php.net is blunt about the options: there are no complete mitigations, updating is the only safe choice.

What happened in the PHP security release October 2026

The PHP team published two advisories in php/php-src on 21 October, both rated critical, and pushed patched builds within about half an hour of each other. The advance notice, sent before the release, rated both issues CVSS v4.0 9.2 and asked users to prepare so they could upgrade the moment builds landed. The first, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), is an RCE via out-of-memory corruption. The second, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), is an RCE via stale global state. Both can be triggered by an unauthenticated request.

Am I affected? The version check that decides it

You are affected if the PHP build serving traffic is older than 8.2.35, 8.3.36, 8.4.27 or 8.5.12 on your branch. The vulnerable ranges map cleanly: below 8.2.35, below 8.3.36, below 8.4.27, below 8.5.12. Note that this is about the version actually handling requests, not the version in your composer.json or your Dockerfile base image label — long-lived containers and patched-then-rolled-back deploys are the usual culprits. If you run managed hosting or a shared panel, the PHP version is set per domain, and it is common to find one staging subdomain still on an old build months after everyone assumed it was retired.

How bad is it, and who is most exposed

php.net calls the risk highest for Apache with mod_php, where a demonstrated exploit triggers before any application code runs. The PHP Foundation's write-up states that on Apache with mod_php an unauthenticated request can trigger this before application code runs, with full remote code execution demonstrated on default settings. Remote code execution was also confirmed on PHP-FPM through application-level code paths, and for CVE-2026-109619 a use-after-free and worker crash were confirmed alongside a demonstrated RCE against a real-world application on Apache with mod_php. Frameworks, WAF rules and authentication layers give you less cover here than usual, because the attack surface includes request parsing and shutdown paths rather than your routes.

What your team should do in the next 24 hours

The action is simple: upgrade to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 on the branch you run, then restart the process manager so workers actually reload. Steps that matter:

• Patch and rebuild, or pull the new package from your distro or vendor repository.
• Restart PHP-FPM, Apache, FrankenPHP or LiteSpeed — new files on disk do nothing for running workers.
• Verify what is serving traffic, not what is on disk: check the version reported by phpinfo() through the live endpoint, or run php -v inside the running container, and confirm the version string ends with the patched build.
• If you have more than one PHP version per server, verify each pool and each vhost separately.
• Watch error logs for OOM messages, worker segfaults, and unexplained 500s in the hours after rolling out.
• If you truly cannot patch today, take the exposed service off the public internet rather than relying on a rule.

What these two bugs actually are

One is about memory exhaustion at the wrong instant; the other is about state left over from the previous request. In CVE-2026-109618, PHP uses longjmp() to exit the current context on out-of-memory errors, and in some contexts request memory is temporarily reachable before it is fully initialized. If an allocation fails at that point, the early exit is not properly accounted for, the request memory is left in an invalid state, and shutdown may then read or branch on it. The advisory notes that several multipart parsing problems can let a request reach OOM while staying within its apparent PHP limits — including a multipart request without a usable declared content length passing the initial postmaxsize check. In CVE-2026-109619, global state — error, session, object and extension state — retained by a worker still points at memory owned by a previous request; a fatal error can abandon an operation before its matching reset, or a nonfatal diagnostic can repopulate error state after shutdown cleared it, producing a use after free.

What AI changes about fixing bugs of this class

AI-assisted review is genuinely useful for this class of bug, but not as a substitute for patching. These are lifecycle bugs — init, shutdown, error paths, early exits — which are exactly the regions a model can be pointed at with a diff and a question like "what happens if this allocation fails here?" You can also use it to triage your own upgrade: feed it your vhost and pool configs and ask which runtime is actually executing for each domain.

Where it does not help is the timing. This release was public, pre-announced, rated 9.2, and exploitable by an unauthenticated request; the gap between advisory and attempted exploitation is short and getting shorter. Tooling that keeps an inventory of runtime versions — not dependency manifests — is worth more than any amount of code review on patch day. The PHP Foundation's own write-up mentions earlier work with Alpha-Omega scanning PHP with a Claude model, which is a fair illustration of the direction: AI is entering the pipeline as a finder of bugs, so expect fewer quiet years and more emergency releases to plan for.

Where to start

Check your live PHP version first — one command against a real endpoint — then patch, restart workers, and verify again. If you run custom PHP applications and want the runtime and deployment side reviewed as part of a broader hardening pass, our cloud and infrastructure work and architecture reviews cover exactly that; the front door to a conversation is here. Maysan Labs has spent enough patch days on client infrastructure to know the boring part is the part that saves you.

PHP 8.2 end of life is two months away

PHP 8.2 reaches end of life on 31 December 2026 and will receive no further security fixes after that date. If you are patching to 8.2.35 today, treat it as a stopgap and put a dated plan behind it: pick your target branch, test your extensions and framework version against it, and schedule the cutover. The 8.2.35 release note says the same thing plainly — plan your upgrade to a supported version. Teams that defer this usually end up doing it under pressure during the next emergency release, which is a worse time to discover a incompatible extension.