PHP Patches Two Critical Unauthenticated RCEs (CVE-2026-109618, CVE-2026-109619): Update Now

On Wednesday, October 21, 2026 at 14:00 UTC, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix two critical vulnerabilities, both rated CVSS v4.0 9.2, that can allow unauthenticated remote code execution. The PHP security team advises: "There are no complete mitigations; updating is the only safe choice."

These are bugs in the PHP runtime, not in a Composer package. That changes how you detect and fix them, as we explain below

TL;DR If you run PHP that serves web requests (PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, LiteSpeed), update to 8.5.12, 8.4.27, 8.3.36, or 8.2.35 today. If you are on 8.1 or older, get a backported package from your distribution or LTS vendor, or upgrade.

What happened

Times are in UTC.

• October 20: The PHP security team published an advance notice of a critical security release scheduled for October 21 at 14:00 UTC. It fixes two vulnerabilities assessed as CVSS v4.0 9.2, with the right reserved to release early if details leak or exploitation is seen in the wild.

• October 21, before 14:00 UTC: Snyk published advisories for both CVEs, SNYK-UNMANAGED-PHP-21347795 (CVE-2026-109618) and SNYK-UNMANAGED-PHP-21347796 (CVE-2026-109619), to alert customers to the action they will need to take and so that monitored projects get a hit the moment the fixed versions are known.

• October 21, 14:00 UTC: The PHP security advisory and the four fixed releases go live. Within about 30 minutes, Snyk's advisories are updated with all relevant details, including affected ranges and fixed versions.

• October 21 onward: Linux distributions (which received the patches in advance) start publishing their own advisories. Snyk publishes advisories for them as they appear, for example SNYK-UBUNTU2604-PHP85-21373920. The running list is at CVE-2026-109618 and CVE-2026-109619.

The two vulnerabilities

Both are in the request lifecycle of the PHP engine, making them reachable before any application code runs. This is one factor that makes these vulnerabilities both widespread and dangerous.

Technical details

CVE-2026-109618, RCE via out-of-memory corruption: Out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup, then treats the invalid data as valid. An attacker who can drive a worker to its memory limit with a malicious request can trigger the interrupt.

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 initialization resets it. In a long-lived worker model that comprises a cross-request use-after-free.

These bugs were found with AI assistance, in a runtime that has been in production for three decades. In a world of LLMs and agents, everybody is still running servers - and the model that found these is the same kind of model attackers now have, which is the premise behind Evo by Snyk: AI-driven security for the applications that agents run on, not only for the agents themselves.

Who is affected

All PHP installations serving web requests are at risk. That covers PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, LiteSpeed, etc. Apache with mod_php is most vulnerable, with a demonstrated exploit in which a single unauthenticated request triggers the attack before application code runs.

PHP 8.1 and older no longer receive updates from the PHP project, so an unpatched 8.1, 8.0, or 7.4 install is affected with no upstream fix. Given the severity, the PHP security team did publish minimal source backports for 7.4, 8.0, and 8.1 for people who build from source or have no LTS vendor.

What you should do now

1. Update. Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Note that 8.2 reaches end of life on December 31, 2026, so if you are on 8.2, this is also your cue to plan the next bump.

2. Check your vendor. Linux distributions and LTS vendors received the patches ahead of release. Pull their updated packages rather than waiting for a source build. A patched distro build can keep an older version number, so check the distro’s advisory or patch level too.

3. Verify what’s actually running. Check the PHP version on each host and image (php -v or the image tag). Scan results alone can’t confirm that an installation is fixed.

4. If you cannot update today, PHP lists mitigations that reduce exposure to specific paths without making an install safe: memory_limit=-1 set where applications cannot override it, a low post_max_size, session.upload_progress.enabled=0 followed by a restart of every worker, and on 8.5 fatal_error_backtraces=0. See the relevant advisory for the caveats on each.

5. On PHP 8.1 or older, upgrade to a supported version or get a backported package from your distribution or LTS vendor. PHP’s source backports for 7.4, 8.0, and 8.1 are a last resort for teams building from source.

The open source side

The PHP security team gave the ecosystem a day's notice with a fixed time, a severity, and no exploitation details. They pre-shared patches with Linux distributions so packaged fixes could be released alongside the source release. They published backports for unsupported versions (7.4, 8.0, 8.1). They told users of a popular volunteer repo (rpms.remirepo.net) that it would not be updated on day one and what to do instead. And their mitigation guidance is very transparent about what each setting does not protect against.

That is what coordinated disclosure looks like when a volunteer-run project does it right. It is also why, at Snyk, we were able to have advisories live before the release and complete shortly after it: a published schedule lets everyone downstream prepare.

Snyk SCA Behavior

Snyk Open Source reads what your application declares in manifest or build files, like composer.json, composer.lock. The PHP interpreter is not a declared dependency. It is installed by a Dockerfile, a distribution package, a platform image, or by hand. A "php": ">=8.2" constraint in composer.json tells you what the application accepts, but not precisely what is deployed.

How the Snyk Platform helps you find exposed PHP

Finding your PHP attack surface with Snyk API & Web

Before you can patch, you need the list. Snyk API & Web's Discovery tab enumerates assets found on your domains and fingerprints their technology stack. Open Discovery, set the Tech filter to PHP, and you have every discovered host and endpoint where PHP was identified, with its risk rating, score, and last-seen date, ready to scan or add as a target.

The same Tech filter is also available in the Targets list, so the applications you added can be narrowed to PHP the same way.

This does not tell you the PHP version. It tells you where to look, which is a crucial step towards remediation.

What we are doing

• Advisories for both CVEs were published before PHP's 14:00 UTC release and updated with affected versions and fix details within about 30 minutes of it.

• Distribution advisories are being imported as each Linux distribution publishes. Ubuntu and Red Hat are available now.

• A Zero Day report for this event is available for Unmanaged and Container projects.

As always, Snyk's security research team is tracking this disclosure and will update the advisories as new information arrives. If you have questions, contact your Snyk account team or Support.

References

• PHP security advisory: Critical remote code execution vulnerabilities, update now (October 21, 2026)

• Snyk Unmanaged advisory for CVE-2026-109618

• Snyk Unmanaged advisory for CVE-2026-109619

• All Snyk advisories for CVE-2026-109618 and CVE-2026-109619

• Snyk Open Source documentation

• Snyk C/C++ Unmanaged scanning documentation