PHP Ships Emergency Fixes for CVE-2026-109618 and CVE-2026-109619

PHP released the emergency fixes it had announced the day before. On October 21, 2026, the project shipped PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to close two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619. PHP's advisory is titled "Critical remote code execution vulnerabilities, update now", and GitHub's advisories for both rate them 9.2 on CVSS v4.0, with no authentication and no user interaction needed.

The release notes settle several questions the leak and the warning left open. They name the affected components, describe how each bug works, and say which web server setups are at most risk. PHP says the highest risk is Apache with mod_php. No exploitation had been reported when the sources used here were published, and the project says updating is the only safe choice. This post covers what changed since the warning, who needs to update, and what to do if you cannot do it today.

What the advisories say about each flaw

Both bugs are memory corruption problems in PHP's request handling, and both share the same CVSS v4.0 vector: network attack, high attack complexity, no privileges, no user interaction, with high impact on confidentiality, integrity and availability. The high attack complexity helps explain why the score is 9.2 and not higher. The advisories also list the same weakness classes for both, starting with use-after-free (CWE-416).

CVE-2026-109618, "RCE via OOM corruption". PHP's out-of-memory handling jumps out of the failing code with longjmp. If that happens while request memory can still be reached before it is fully set up, shutdown later processes invalid state. The advisory stresses that the failed allocation does not have to be related to the damaged memory. Multipart request parsing is the trigger. The authors validated full remote code execution over HTTP against mod_php with default PHP input and memory limits. For PHP-FPM, no complete exploit has been demonstrated, FrankenPHP is considered likely susceptible from source analysis, and for LiteSpeed (LSAPI) application-specific exploits are judged likely but unvalidated.

CVE-2026-109619, "RCE via stale global state". PHP workers keep global state (errors, sessions, objects, extensions) between requests, and some of it can end up pointing at memory from a finished request, which gives a use-after-free. The advisory confirms three ways to reach it: configuration diagnostics raised before a request starts, mainly through Apache per-directory settings; session upload progress, which is enabled by default and does not require the application to call session_start(); and, on PHP 8.5, fatal error backtraces when that setting is on. Remote code execution through the session path was validated against both mod_php and PHP-FPM.

Two claims from the warning phase did not survive. The leaked score of 10.0 became 9.2, and the "PHP 5 onward" range is not confirmed by either advisory, which list affected versions only below the four fixed releases. Both advisories credit the same group of reporters and the same four PHP maintainers for the fixes. The changelog lists the fix under Core, as a change to avoid state corruption via bailout.

Who is affected

Both advisories list every version below the fixed release of each supported branch as affected. If you run one of the four branches below, the fix is a single version bump.

The notice says the flaws reach all web-serving PHP, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and that the risk is highest for mod_php, where an unauthenticated request can trigger the attack before any application code runs.

PHP 8.1 and older no longer receive updates from the project, and no new release exists for them. PHP did publish minimal source backports for 7.4, 8.0 and 8.1 as branches in its GitHub repository, named PHP-7.4-CVE-2026-109618-109619 and so on. These are source branches, not releases, and the notice does not say in words that those versions are affected, though shipping backports for them implies it. Nothing from PHP mentions PHP 5 or 7.0 through 7.3.

Many servers do not take PHP straight from php.net. PHP says Linux distributions and long-term-support vendors received the patches in advance, and that some provide backported fixes for 8.1 and older, so check your vendor's package. The volunteer Remi repository said it would not have updates on release day.

One small inconsistency in the sources: the PHP news archive dates the releases October 21, while the changelog heading for 8.5.12 reads October 22. The archive and the advisories agree on October 21.

Doubt about the leaked exploit does not change the advice

While the fixes were still pending, some of the public discussion leaned toward reassurance. One news outlet reported that the circulating proof-of-concept code did not fire, and cited an anonymous audit arguing that the upload-progress path does not exist. That reading is now at odds with PHP's own advisories. GitHub's entry for CVE-2026-109619 lists the session path as confirmed and says remote code execution through it was validated against mod_php and PHP-FPM, and the entry for CVE-2026-109618 reports full remote code execution against mod_php with default limits. A broken public exploit tells you about that exploit, not about the bug.

The advisories also change who should worry first. The warning phase gave no component, so every PHP server looked equal. Now the picture has a gradient: mod_php with default settings is the validated target, FPM has a validated path through sessions even though no complete FPM exploit has been demonstrated for the memory bug, and FrankenPHP and LiteSpeed are judged likely susceptible. High attack complexity in the vector means exploitation is not trivial, but "hard" has a short shelf life once the technical write-up and the patch are both public.

Timing is the other fact worth noting. PHP's notice went out at 19:33 UTC on October 20, and the release followed about 18 hours later, a day ahead of the October 22 disclosure the leak described. The notice says the project reserved the right to release earlier if details went public or exploitation appeared. Teams that had prepared a patch plan the evening before could move at once, and the rest started the day behind.

What to do now

PHP states there are no complete mitigations and that updating is the only safe choice, so the order of work starts with the update.

1. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Start with internet-facing servers, and with mod_php setups first. Restart the web server or the FPM pools afterward so that old workers do not keep running with the previous code.
2. Use your vendor's packages where you have them. Check your Linux distribution, hosting provider or control panel (cPanel, Plesk) for patched packages, since many systems do not install PHP from php.net. PHP bundled inside appliances and Windows software follows the vendor's schedule.
3. Handle PHP 8.1 and older separately. Ask your distribution or LTS vendor whether it backported the fix, look at the PHP-7.4, PHP-8.0 and PHP-8.1 source branches PHP published, or move the application to a supported branch. Note that 8.2 also reaches end of life on December 31, 2026.
4. If you cannot update today, apply PHP's partial measures and treat them as temporary. For CVE-2026-109618, PHP suggests a memory_limit of -1 enforced where applications cannot override it, post_max_size of 8M without uploads or 32M with uploads (with upload_max_filesize below it), the same limits enforced at the front end, and a container or cgroup memory limit. It warns against using RLIMIT_AS or RLIMIT_DATA instead. For CVE-2026-109619, set session.upload_progress.enabled=0 in php.ini or the server configuration (not through ini_set or .user.ini) and restart every worker, and on PHP 8.5 set fatal_error_backtraces=0. The advisory says hiding diagnostics with error_reporting or display_errors does not help.
5. Watch for what comes after. Alert when php-fpm, php-cgi, httpd or apache2 start shells, interpreters or download tools. If a server looks suspicious, isolate it, keep the web server and PHP logs, and look for web shells, new files in the web root, new cron jobs, scheduled tasks and new accounts.

Takeaway

The wait is over and the guidance is simple: update, restart the workers, and do not read a broken public exploit as a sign that the bugs are harmless. PHP's own advisories confirm remote code execution against default mod_php setups and through the session path on FPM. If you want to follow these two CVEs as NVD, scoring and exploitation data catch up, you can track PHP on VulnTracker and see their status and affected versions as they change.

References

Vendor: PHP security advisory of October 21, 2026, PHP advance notice of October 20, GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp. NVD: CVE-2026-109618 and CVE-2026-109619. Analysis: watchTowr FAQ, Huntress and The Hacker News.